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I MANAGEMENT  SUMMARY 


MANAGEMENT  SUMMARY 


There  are  large  software  maintenance  markets  for  maintaining  both  govern- 
ment ADP  and  ECS  software,  as  shown  in  Exhibit  l-l. 

ADP,  or  Automatic  Data  Processing,  includes  systems  used  for  conven- 
tional administrative  processing  in  DOD  and  all  civilian  agencies. 

ECS,  or  Embedded  Computer  Systems,  includes  software  supporting 
weapons  systems  and  other  uniquely  military  applications. 

However,  the  ECS  market  is  much  more  attractive  than  the  ADP  market,  as 
shown  in  Exhibit  1-2. 

There  are  few  linkages  between  the  two  markets,  as  shown  in  Exhibit  1-3. 

Consequently,  INPUT  believes  that  Ford  Aerospace  and  Communications 
Corporation  (FACC)  should  focus  on  and  enter  the  ECS  software  maintenance 
market. 

There  are,  however,  some  potential  negative  factors  bearing  on  how  to  enter 
the  market,  as  shown  in  Exhibit  1-4. 

In  general,  entry  will  be  successful  if  it  is  market  oriented,  rather  than 
technically  oriented.  A solid  technical  base  is  a prerequisite  for 
success,  though,  as  shown  in  Exhibit  1-5. 
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EXHIBIT  1-1 


INFLATION-ADJUSTED  SOFTWARE  MAINTENANCE 
CONTRACTOR  MARKET  GROWTH,  1 981-1  990 

($  billions) 


1 990 

REAL 

GROWTH 

(percent) 

SYSTEMS 

1981 

THEN- 

YEAR 

CONSTANT 

DOLLARS 

ADP 

$0,540 

$2.7 

$1.3 

140% 

ECS 

0.  900 

16.4 

7.7 

755 

EXHIBIT  1-2 


u 


ECS  VERSUS  ADP  SOFTWARE  MAINTENANCE  MARKET 


MARKET  FACTOR 

ECS 

ADP 

1 990  Market  Size  Estimate 
("Then  Year"  $) 

$16.4  billion 

$2.7  billion 

1981-1990  Real  Growth 
(Excluding  Inflation) 

755% 

140% 

Independence  from 
Politics 

Medium  /High 

Low 

Leverage  Potential 

High 

Medium  / Low 

FACC  Market  Knowledge 

Medium  / Low 

Low 

Synergy  with  Current 
FACC  Business 

High  (Marketing) 

Low 

Self-Aware  Competitors 

No 

Yes 
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EXHIBIT  1-3 


ECS  AND  ADP  SOFTWARE 
MAINTENANCE  LINKAGES 


AREA 

EXTENT  OF  LINKAGE 

Buying  Points 

Low  (Civilian,  None:  Military,  Little) 

Buying  Process 

Low/Medium:  Brooks  Act  Environment 
Perceived  to  be  Quite  Different 

Skills 

Low  /Medium:  Little  Appreciation  of 
Systems  Engineering  Approach  in 
ADP 

T echniques 

Medium:  Software  Techniques  Trans- 
ferable to  ADP:  However,  Unappreciated 

Systems  Knowledge 

Low 

- 4 - 


INPL 


EXHIBIT  1-4 


.0 


ECS  SOFTWARE  MAINTENANCE: 

POSITIVE  AND  NEGATIVE  MARKET  ENTRY  FACTORS 


• Positive 

Large,  growing  market 
Perceived  need 

Not  yet  widely  perceived  as  a discrete  business 
- FACC  skill  base  (actual  and  perceived)  advantageous 

Could  be  synergistic  and  complementary  to  existing  business 

% Negative 

Software  maintenance:  low  image,  in  general 
High  skills  required 

• For  key  staff,  at  minimum 

• Potential  for  conflict  with  current  FACC  activities 
Personnel 

• Shortage 

• Turnover 
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EXHIBIT  1-5 


SOFTWARE  BUSINESS  KEYS  FOR  SUCCESS 


EXPERTISE  PERCEIVED 


UNDERSTANDING  OF  CUSTOMER 


UNDERSTANDING  OF  SYSTEM 


MANAGEMENT  PROCESS 


COST  ESTIMATE/CONTROL 


TECHNICAL  EXPERTISE 


INPUT  believes  that  FACC  ECS  software  development  and  maintenance 
activities  should  be  organizationally  separate  if  maintenance  is  to  be  success- 
ful. 

Current  FACC  strengths  and  weaknesses  should  be  assessed  for  particular 
markets  and  products. 

This  should  include  any  analysis  of  ECS  software  issues,  including: 

. Current  FACC  personnel  quality. 

. Internal  FACC  assessment  of  jobs. 

. Customer  assessment  of  jobs. 

. FACC  product/system  experience. 

. Jobs  not  bid  or  lost:  analysis. 

The  results  of  this  analysis  may  be  the  determining  factor  in  selecting 
certain  product/market  combinations,  since  few,  if  any,  product/market 
combinations  could  be  excluded  now  from  consideration:  they  will  all 
be  growing. 

FACC  can  enter  the  ECS  software  maintenance  business  by  a combination  of: 
Drawing  on  internal  capabilities. 

Through  newly  hired  individuals. 

Acquiring  small  companies. 

It  is  critical  that  the  Engineering  Services  Division  should  obtain  additional 
information  on: 
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, The  software  process. 


Weapons  systems. 

Maintenance  plans  and  philosophies  of  individual  services. 
This  information  can  be  obtained  by: 

Studying  the  documentation  obtained  for  this  study. 
Receiving  additional  briefings  from  INPUT. 

Attending  conferences  and  seminars. 


Receiving  information  from  other  FACC  units. 


1 1 


INTRODUCTION 


II 


INTRODUCTION 


A.  OVERVIEW 

• The  Ford  Aerospace  and  Communications  Corporation  (FACC)  engaged  INPUT 
in  December  1981  to  study  the  business  opportunities  for  FACC  in  supplying 
software  maintenance  services. 

• Originally,  the  study  was  designed  to  examine  the  following  market  areas: 

DOD:  Embedded  Computer  Systems  (ECS). 

DOD:  Automatic  Data  Processing  (ADP). 

Civilian  federal  agencies. 

Business  (banking  and  energy). 

Software  vendors. 

• At  an  early  stage  in  INPUT'S  investigations,  two  points  became  clear: 

The  government  market  was  much  more  attractive  than  the  remaining 
markets. 
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This  conclusion  was  reached  as  a result  of  the  initial  research  for 
this  stud/  combined  with  other  data  which  INPUT  had  available 
from  prior  work. 

Government  respondents  were  extremely  responsive  in  face-to-face 
interviews.  They  were  much  less  willing,  however,  to  engage  in 
telephone  interviews. 

. This  was  understandable,  given  the  security  issues  on  the  ECS 
side  and  political  sensitivities  in  many  of  the  civilian  agencies. 

• Because  of  these  two  factors,  INPUT  recommended  and  FACC  concurred  in 
modifying  the  scope  and  methodology  of  the  project: 

The  study  would  focus  on  the  government  market. 

The  interview  program  would  concentrate  on  on-site  interviews  for 
government  respondents,  as  shown  in  Exhibit  II- 1 . 


B.  METHODOLOGY 


• INPUT  was  very  fortunate  in  being  able  to  interview  authoritative  and 
forthcoming  respondents.  Appendix  A summarizes  the  agencies  and  types  of 
personnel  contacted  in  the  ECS  area  and  Appendix  B in  the  ADP  area. 

In  the  embedded  systems  area  INPUT  contacted  approximately  200 
individuals  in  order  to  interview  the  "right"  20  people. 

. These  were  middle  level  personnel  for  the  most  part  who  had  an 
understanding  of  both  the  technical  and  policy  issues  involved. 
The  average  calibre  of  the  interviewee  was  very  high. 
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EXHIBIT  11-1 


INTERVIEW  PROGRAM 


AREA 

ON-SITE 

TELEPHONE 

TOTAL 

ECS 

20 

0 

20 

ADP 

21 

1 

22 

Vendors 

0 

13 

13 

Total 

41 

14 

55 

INPUT 

YFA9 


. Many  of  the  ECS  respondents  had  served  in  other  programs  and 
jobs  in  the  ECS  area  and  were  consequently  able  to  bring  a wide 
perspective  to  bear  in  many  of  their  observations. 

Appendix  C shows  the  questionnaire  used  for  ECS  respondents  and 

Appendix  D,  for  ADP  respondents. 

• INPUT  also  interviewed  software  vendor  personnel.  As  it  became  clear 
that  the  ECS  area  offered  the  most  opportunities,  the  interviewees  here  were 
limited  to  people  active  in  the  ECS  software  maintenance  area.  Experts  for 
interviewing  were  among  those  who  had  published  papers  on  the  subject  or 
otherwise  played  a leading  role  in  the  field. 

Their  company  affiliation  is  shown  in  Appendix  E. 

The  questionnaire  used  is  in  Appendix  F. 

• Interviews  were  conducted  in  January  through  March  1982. 

Questionnaires  were  reviewed  at  a meeting  with  EACC  personnel  in 

January  I 982. 

• The  questionnaires  were  very  useful  tools.  However,  for  most  interviews, 
especially  those  with  ECS  respondents,  they  provided  nothing  more  than 
baseline  data.  The  interviews  were  extremely  valuable  in  providing  additional 
information  on: 

Quantitative  data. 

Future  plans. 

Understanding  respondent  motivations. 


- 12  - 


INPl 


These  Jast  two  points  are  extremely  important  because  the  quantitative  data 
has,  to  put  it  mildly,  limitations. 

In  addition,  a number  of  government  ECS  respondents  are  experts  in  their  own 
right  and  their  views  are  important. 

In  a number  of  cases  respondents  reviewed  internal  documents  and  briefing 
books  with  INPUT  in  the  course  of  the  interview.  In  several  cases  the  factors 
that  would  go  into  future  policy  decisions  were  analyzed  and  evaluated  by 
respondents. 

Many  key  documents  were  collected  in  the  course  of  the  study  (see  the  list  in 
Appendix  G). 

INPUT  was  fortunate  in  being  able  to  interview  the  authors  or  others 
closely  associated  with  these  documents  in  a number  of  cases;  e.g.: 

. The  ECS  software  maintenance  plans  for  the  Air  Force  and 
Army. 

. GAO  software  maintenance  reports. 

. The  Naval  ECS  Conference. 

. The  SSA  System  Modernization  Plan. 

INPUT  also  drew  upon  its  knowledge  of  software  issues,  software  maintenance 
issues,  and  the  computer  services  industry  in  both  the  analysis  of  the  data  and 
the  conclusions  and  recommendations. 

The  material  in  this  report  was  the  subject  of  a presentation  to  FACC 
personnel  at  Willow  Grove,  Pennsylvania,  on  April  13,  1982. 
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c. 


ORGANIZATION  OF  THIS  REPORT 


• The  issues  involving  software  maintenance  cannot  be  removed  from  the 
content  of  wider  hardware  and  software  issues,  especially  in  the  ECS  area. 

• This  report  will  be  organized  to: 

Discuss  ECS  issues  and  make  recommendations. 

Discuss  ADP  issues  and  make  recommendations. 

Outline  the  next  steps  for  FACC. 

• The  ECS  chapters  include: 

Chapter  III:  ECS  Overview. 

Chapter  IV:  ECS  Software. 

Chapter  V:  ECS  Software  Maintenance. 

Chapter  VI:  The  ECS  Software  Maintenance  Business  Issues. 

Chapter  VII:  ECS  Summary  and  Recommendations. 

• The  ADP  chapters  will  include: 

Chapter  VIII:  The  Federal  ADP  Environment  and  Software  Maintenance 
Opportunities. 

Chapter  IX:  ADP  Software  Maintenance:  Summary  and  Recommenda- 
tions. 

• Chapter  X summarizes  INPUT'S  conclusions  and  outlines  the  next  steps  for 
FACC. 
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Ill  EMBEDDED  COMPUTER  SYSTEMS  OVERVIEW 


Ill 


EMBEDDED  COMPUTER  SYSTEMS  OVERVIEW 


A.  DEFINITIONS  AND  EXAMPLES 


• An  embedded  computer  system  is  one  that  is  closely  associated  with  a military 
weapons  or  communication  system,  as  shown  in  Exhibit  lll-l. 

• There  is  a complex  of  characteristics  associated  with  an  ECS,  as  shown  in 
Exhibit  111-2. 

The  real  time  attributes  are  perhaps  the  single  most  significant 
characteristic.  This  is  illustrated  in  Exhibit  1 1 1-3,  which  shows  an  ECS 
schematic. 

• ECSs  are  used  in  a great  variety  of  ways,  as  shown  in  Exhibit  111-4. 

B.  GROWTH 


• The  growth  in  the  intensity  of  use  of  individual  ECSs  is  illustrated  in  Exhibit 
1 1 1-5  where  avionics  ECSs  have  increased  in  intensity  by  two  orders  of 
magnitude  in  15  years. 
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EXHIBIT  1 1 1-1 


EMBEDDED  COMPUTER  SYSTEMS  DEFINITION 


• Integral  to  electronic  or  electromechanical  system. 

From  design,  procurement,  and  operations  viewpoints. 

• Key  attributes. 

Developed,  acquired,  and  operated  under  decentralized 
management  (DOD  directives  5000.  1 and  5000.2). 

Physically  incorporated  into  a larger  system  whose 
function  is  not  data  processing. 

Integral  to,  or  supportive  of,  a larger  system  from  a 
design,  procurement,  and  operations  viewpoint. 

Outputs  include  information,  control  signals,  and  com- 
puter aids. 
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ECS  CHARACTERISTICS 


• Real  time. 

• Simultaneous  hardware  and  software  development. 

• Transportable/ deployable. 

• Generally  militarized. 

• Special  purpose  or  one-of-a-kind. 

• Programs  machine-dependent. 

• Designed  to  fit  into  larger,  non-DP  system. 

• Software  and/or  hardware  size  often  a constraint. 
® Tailored  programming  languages. 

• Specialized  computer  equipment. 

• Development/acquisition /support  as  a process 
(Configuration  item) . 

• Need  high-reliability  software. 

• Extensive/expensive  test  programs. 


INPUT 

VFA2 


EXHIBIT  1 1 1-3 


TYPICAL  WEAPONS  SYSTEM 
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EXHIBIT  1 1 1 -4 


ECS  APPLICATIONS:  EXAMPLES 


• Fuel  savings  advisory  systems. 

• Optical  sensor  processing /control . 

• Navigation. 

• Stores  management  and  weapon  delivery. 

• Fuel  flow  and  center-or-gravity  control, 
e Controls/displays  management. 

• Electronic  warfare. 

• Encryption /decryption . 

• Radio  frequency  controllers. 

• Auto-land  systems. 

• Radar  processors. 

• Engine  malfunction  detection /diagnosis, 
o Automatic  test  equipment. 

• Intelligence  processing. 

• Battle  management  systems. 

jr 

• Command,  control,  and  communications. 

• Terminals  guidance  and  fuzing  control. 

• Data  compression. 

• Digital  voice  synthesis/recognition. 
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ON-BOARD  COMPUTER  MEMORY  (X1000  WORDS) 


l 


EXHIBIT  1 1 1-5 


ECS  GROWTH:  AVIONICS  EXAMPLE 


SOURCE:  ELECTRONIC  INDUSTRY  ASSOCIATION  STUDY 


!NPI 
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, A 1 1 indications  are  that  this  trend  will  continue,  even  in  already  fielded 
weapons,  due  to  upgrades  and  retrofits. 

• This  same  kind  of  growth  is  seen  on  a larger  scale  in  the  recent  Electronics 
Industry  Association  (E1A)  ECS  market  forecast,  as  shown  in  Exhibit  111-6. 

This  study  was  conducted  by  an  industry  team  that  spent  several  months 
and  conducted  several  dozen  interviews.  It  was  the  first  study  of  its 
kind. 

It  is  especially  important  to  note  that  most  of  the  growth  occurs  in  the 
software  area. 

• It  should  be  noted  here  that  all  dollar  figures  in  the  ECS  area  have  a rather 
wide  potential  for  deviation,  for  reasons  that  will  be  explored  in  greater  depth 
in  Chapter  IV. 

This  is  widely  recognized  in  both  industry  and  military  circles. 
However,  before  the  EIA  study,  there  was  no  commonly  accepted 
estimate  for  the  totality  of  ECS  expenditures,  present  and  future. 

. The  EIA  figures  have  received  wide  acceptance  by  military 
planners.  They  were  cited  as  the  best  available  figures  by 
several  respondents  and  have  appeared  in  several  documents 
published  by  the  military  in  the  latter  half  of  1981. 


C.  MAJOR  ECS  ISSUES 


• The  most  significant  aspect  of  ECSs  is  their  increasing  importance  to  the 
defense  effort;  e.g.: 
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EXHIBIT  III-6 


ECS  MARKET 
(Excludes  Classified) 


$38  - 
36  - 


1980 

1981 

1982 

1983 

1984 

1985 

1986 

1987 

1988 

1989 

1990 

$ BILLION 
(’’THEN-YEAR” 
DOLLARS) 

1980 

1981 

1982 

1983 

1984 

1985 

1986 

1987 

1988 

1989 

1990 

HARDWARE 

$1.28 

$1.58 

$1.81 

$2.08 

$2.36 

$2.75 

$3.20 

$3.73 

$4.34 

$5.06 

$5.89 

SOFTWARE 

2.82 

4.49 

5.62 

7.16 

8.95 

11.17 

13.90 

17.16 

21.20 

26.15 

32.10 

TOTAL 

$4.10 

$6.07 

$7.43 

$9.24 

$11.31 

$13.92 

$17.10 

$20.89 

$25.54 

$31.21 

$37.99 

SOURCE:  ELECTRONICS  INDUSTRY  ASSOCIATION  STUDY 


„The  Cruise  missile  could  not  exist  as  a concept  or  a weapon  without 
ECS. 

Associated  with  the  importance  of  ECSs  has  become  their  size. 

Many  ECSs  have  been  constrained  by  the  physical  space  available  to 
them  in  many  weapons  systems  (e.g.,  avionics,  missiles,  and  ordnance). 

Where  not  subject  to  such  constraints,  these  systems  can  become 
extremely  large;  e.g.: 

. Ten  million  lines  of  code  in  the  SAC  mission  planning  system. 

Advances  in  hardware  will  continue;  e.g.,  the  Very  High  Speed  Inte- 
grated Circuit  and  Josephson  Junction  technologies. 

. These  will  greatly  increase  the  computing  power  and  associated 

complexity  possible. 

The  two  previous  issues,  criticality  and  complexity,  have  helped  create  what  is 
both  an  opportunity  and  what  could  become  an  insurmountable  problem: 
interoperability. 

At  its  simplest,  interoperability  refers  to  weapons  systems  sharing  components 
or  armament,  as  shown  in  Exhibit  1 11-7. 

However,  the  real  issues  (and  growth)  are  occurring  in  the  areas  where 
physical  interoperability  is  not  paramount. 

Looking  at  avionics  from  functional  avionics  categories,  in  the  past  the 
different  systems  could  operate  in  semi-isolation.  Now,  except  for 
automatic  test  equipment  (ATE),  there  is  increasing  functional  over- 
lapping between  subsystems,  as  shown  in  Exhibit  1 1 1-8. 
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EXHIBIT  111-7 


ECS  COMMONALITIES 


I 


EXHIBIT  1 1 1-8 


GROWING  INTEROPERABILITY  ISSUE: 
AVIONICS  EXAMPLE 


AVIONICS  CATEGORIES 

ROLES 

ATD 

ATE 

C-E 

EW 

OFP 

Weapon  System  Concurrency 

X 

Interagency  Shared  Software 
Support 

X 

Intelligence  Data  Usage 

X 

X 

X 

Rapid  Reprogramming 

X 

X 

X 

Frequent  Changes 

X 

X 

X 

Nuclear  Safety 

X 

Increased  Functional 
Overlapping 

X 

X 

X 

X 

KEY: 

ATD  = Aircrew  Training  Devices 
ATE  = Automatic  Test  Equipment 
C-E  = Communications-EJectronics 
EW  = Electronic  Warfare 
OFP  = Operational  Flight  Programs 
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• This  example  examined  ECS  subsystems  within  a single  weapons  system.  The 
issues  become  much  more  complex  when  dealing,  for  example,  with  the  Army's 
100+  battlefield  ECS. 

They  should,  in  principle,  be  able  to  interact  and  support  one  another  in 
a real-time  basis. 

. Again,  in  principle,  the  Army's  ECS  should  be  able  to  be 
interoperable  with  certain  Air  Force  ECSs. 

. When  allies'  ECSs  are  taken  into  account,  the  result  is  mind 
boggling. 

• Exhibit  111-9  is  a simple  illustration  of  the  logical  complexities  involved. 

As  independent  entities,  Systems  A and  B have  only  36  pairs  of  logical 
interfaces  to  contend  with. 

As  integrated  (interoperable)  systems  there  is  more  than  an  order  of 
magnitude  complexity  to  be  concerned  with. 

In  the  real  world  of  interoperability,  there  would  be  many  more 
systems,  with  many  more  combinations  of  interactions  possible. 


D.  ECS  DRIVING  FORCES 


• The  biggest  force  driving  ECS  growth  is  the  policy  and  strategic  goal  of 
counterbalancing  U.S.  opponents'  quantitative  strengths  with  qualitative 
superiority.  ECSs  are  certainly  one  area  where  the  U.S.  maintains  an 
advantage. 
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EXHIBIT  111-9 


INDEPENDENT  AND  INTEROPERABLE  SYSTEMS 


System  A System  B 

Nine  (9)  modules  each. 

Thirty-six  (36)  different  single  interface  combinations  each. 


• Six-hundred  and  thirty  (630)  paired  combinations. 
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.There  is  a danger,  though,  that  ECS  development  will  be  undertaken  in 
a way  that  will  not  further  these  goals.  Danger  points  include: 

. Nonstandard  hardware  and  software. 

. Unreliable  and  unmaintainable  systems  (especially  from  a 
software  standpoint). 

. Raising  interoperability  needs  beyond  the  point  where  they  can 
be  met. 

9 Advances  in  technology  itself  are  also  very  strong  drivers  of  ECS,  as  shown  in 
Exhibit  III-IO. 

The  software  issues  are  addressed  in  the  next  chapter. 
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EXHIBIT  IH-10 


TECHNOLOGICAL  DRIVERS  OF  ECS 


• Very  high  speed  integrated  circuits 
(VHSIC) . 

9 Fiber  optics. 

• Microprocessors. 

Especially,  off-the-shelf. 

• Software  flexibility. 

• ADA. 

• ADA's  successor. 
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IV  ECS  SOFTWARE 


IV 


ECS  SOFTWARE 


A.  STUDY  OVERVIEW 


I.  GOALS 

• INPUT'S  interviews  and  other  research  had  two  major  goals: 

To  understand  and  explain  the  linkages  between  different  issues. 

To  understand  the  planning  process. 

• There  are  several  related  linkage  issues: 

The  relationship  between  ECS  software  development  and  software 

maintenance  is  the  first.  Two  areas  are  involved: 

. Functional  or  operational  linkages:  From  a technical  standpoint, 
how  much  are  ECS  software  development  and  maintenance 
alike?  Are  techniques,  knowledge,  and  people  transferable? 
Should  they  be? 

. Organizational  linkages:  How  are  development  and  maintenance 
organized?  How  separated  should  they  be?  What  are  the 
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tradeoffs  in  having  the  two  functions  closely  associated  or  quite 
distinct? 

The  relationships  between  hardware  and  software  are  constantly 
changing.  What  are  the  trends?  What  are  the  implications  for  software 
maintenance? 

Finally,  there  is  the  very  important  issue  of  the  similarities  and 
differences  between  the  Army,  Navy,  and  Air  Force.  From  a business 
standpoint,  this  is  at  least  as  important  as  the  others. 

• The  plans  and  evolving  policies  of  ECS  software  and  ECS  software  mainte- 
nance are  important  ones  from  the  standpoint  of  entering  the  software 
maintenance  business.  This  is  so  for  several  reasons: 

Current  policies  are  admittedly  unsatisfactory  and  will  not  remain. 

ECS  software  will  have  a long  life  and  maintenance  cycle.  Hence,  the 
same  substantive  work  may  be  conducted  over  the  span  of  several 
different  software  philosophies. 

External  start-up  business  planning  (and  ongoing  planning)  will  be  more 
successful  if  it  aims  at  the  next  business  environment  rather  than  the 
current  one. 

• Therefore,  it  is  useful  if  current  practice  and  proposal  plans  are  contrasted  so 
that  the  magnitude  and  potential  effects  of  these  changes  can  be  gauged. 

• In  addition,  INPUT  assesses,  where  warranted,  the  realism  and  likely  success 
of  current  plans. 

There  is  no  point  in  aligning  a new  business  with  an  external  plan  that 
has  a high  probability  of  failure. 
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• These  goals  and  issues  will  be  pursued  throughout  this  chapter  and  the  three 
that  follow  which  focus  on  ECS  software  issues. 

2.  ECS  SOFTWARE  ENVIRONMENT 

• This  is  a time  of  ferment  and  excitement  in  the  ECS  software  world.  The 
people  in  it  realize  that  the  next  10  years  will  be  their  years.  Many  of  them 
(especially  those  with  broader  views)  are  also  somewhat  frightened:  Can  they, 
in  fact,  meet  expectations? 

• It  was  largely  due  to  this  mixture  of  emotions  that  virtually  all  of  the  people 
that  INPUT  wanted  to  interview  for  this  study  were  not  just  willing  to  be 
interviewed,  but  wanted  to  be  interviewed. 

ECS  software,  especially  ECS  software  maintenance,  suffers  from  a 
dearth  of  information.  INPUT'S  standard  quid  pro  quo  of  a copy  of  the 
study  summary  in  return  for  an  interview  was  very  attractive. 

. In  fact,  a number  of  those  interviewed  had  not  seen  a copy  of  the 
EIA  study  and  were  very  appreciative  of  receiving  a copy  of 
that. 

This  is  related  to  the  second,  and  perhaps  more  important  reason:  most 
of  the  respondents  interviewed  were  at  or  near  the  top  of  a specialized 
technical  pyramid  and  were  a key  interface  to  the  policy  organization, 
as  shown  in  Exhibit  IV—  I . They  had  few  people  they  could  talk  to:  the 
policy  people  couldn't  understand  or  were  not  interested  in  the  tech- 
nology and  vice  versa. 

. Wherever  INPUT  started  in  arranging  interviews  (in  the  middle 
of  the  upper  pyramid  or  in  one  of  the  lower  pyramids),  the  path 
always  led  back  to  one  of  these  key  interface  people. 

An  outsider  who  professed  interest  and  discretion  was  seized  on  avidly. 
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EXHIBIT  IV-1 


POLICY  AND  TECHNICAL  PYRAMIDS 


INF 

VCA' 
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. These  ECS  interviews  often  went  on  for  well  over  two  hours, 
about  three  times  the  length  of  the  typical  on-site  interview. 

The  technical  pyramids,  even  within  the  same  service,  tend  to  be 
isolated  from  each  other. 

. There  are  marketing  implications  for  this  (which  will  be  dis- 
cussed at  greater  length  in  Chapter  VI).  In  brief,  one  effect  is 
for  services  personnel  to  relate  more  easily  to  contractors  (or  in 
INPUT'S  case,  a contractor's  contractor)  than  to  their  own  kind. 


B.  RELATION  OF  HARDWARE  AND  SOFTWARE 


• For  some  time  there  has  been  a trend  for  software  costs  to  increase  relative 
to  hardware  costs.  This  is  a phenomenon  visible  in  both  the  ECS  and 
conventional  data  processing  fields.  Exhibit  IV-2  shows  the  general  relation- 
ship over  time. 

Hardware  costs  often  fall  in  absolute  terms;  and  almost  always  in 
relation  to  processing  accomplished. 

There  have  been  very  few  analogous  advances  in  software  productivity. 

Another  trend,  especially  visible  in  the  ECS  area,  has  been  to  substitute 
software  for  hardware  functions. 

. Such  substitution  makes  it  much  easier  to  be  flexible  after 
deployment.  It  is  also,  unfortunately,  used  as  a political 
expedient  when  setting  out  original  requirements.  ("We're  not 
sure  what  we  want,  so  let's  put  it  into  software.") 
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EXHIBIT  1V-2 


GENERAL  HARDWARE /SOFTWARE  COST  TRENDS 


(Adapted  from  Barry  Boehm) 


,The  advantage  of  having  functions  in  software  rather  than  hardware 
was  shown  when  parallel  modifications  were  made  to  different  models 
of  the  F-l  I I.  In  some  models  the  same  modification  was  a hardware 
change,  in  others  a software  change. 

. Exhibit  IV-3  contrasts  the  time  and  expense  required. 

. The  software  change  was  accomplished  faster  and  two  orders  of 
magnitude  more  cheaply. 

It  has  been  this  kind  of  experience  which  has  made  the  military  services  so 
enthusiastic  for  not  just  ECS,  but  for  ECS  software. 

The  Air  Force,  for  example,  spends  about  $300  to  $400  million  annually 
on  avionics  hardware,  but  over  three  times  that  amount  on  avionics 
software. 

Current  estimates  are  that  ECS  hardware  now  accounts  for  about  50%  of  ECS 
costs.  This  should  fall  to  about  35%  by  1990. 

It  should  be  stressed,  though,  that  ECS  software  is  no  cure-all.  The  World 
Wide  Military  Command  and  Communications  Systems  (WWMCCS)  is  in  many 
circles  thought  to  be  a failure,  or  at  the  most  only  a partial  success. 

Its  hardware  costs  to  date  have  been  $50  to  $100  million,  while  its 
software  costs  have  been  about  $700  million. 

. The  software  effort  has  tried,  unsuccessfully,  to  make  up  both 

for  hardware  problems  and,  more  basically,  for  shortcomings  in 
concept  and  design. 

It  is  useful  to  contrast  the  hardware  and  software  life  cycles  as  is  done  in 
Exhibit  IV-4.  Many  parts  of  the  two  processes  are  similar. 
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EXHIBIT  I V-3 


I 


ADVANTAGES  OF  SOFTWARE  VERSUS 
HARDWARE  MODIFICATIONS 


CASE 

HARDWARE 

SOFTWARE 

Case  1 

Cost  ($  millions) 

$ 5.3 

$ 0.1 

Months 

42 

16 

Case  2 

Cost  ($  millions) 

$ 1.05 

$ 0.02 

Months 

36 

10 

Case  3 

Cost  ($  millions) 

$ 8.0 

$ 0.02 

Months 

78 

15 

Source:  Internal  Air  Force  study  on  same  modifications 
to  F—  111  models  with  and  without  embedded 
computer  systems. 
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EXHIBIT  I V-4 


HARDWARE/SOFTWARE  LIFE  CYCLE  COMPARISONS 


HARDWARE 

SOFTWARE 

Development 

Determine  User  Requirements 

Develop  Product  Concept 
(Functional  Design) 

Specify  Component  Design 
(Detailed  Design) 

Build  and  Test  Prototype 

Develop  Manufacturing 
T echniques 

Determine  User  Requirements 

Develop  Product  Concept 
(Functional  Design) 

Specify  Component  Design 
(Detailed  Design) 

Implement  and  Test  Programs* 

Manufacturing/ 

Installation 

Manufacture  Product 

Make  Product  Available 
to  and  T rain  User 

Copy  Programs* 

Make  Program  Available  to  and 
Train  User 

Maintenance/ 

Maintenance  (Correct  Com- 

Maintenance  (Correct  Implemen- 

Improvement 

ponent  Failures) 

Recall  Product  to  Correct 
Design  Flaws 

Enhance  Product 

tation  and  Design  Errors)* 

Maintenance  (Provide  Enhanced 
Capabilities:  Adapted  to 

Changed  User  Environment) 

Phase-Out 

Unit  is  Unusable  and  Unrepair- 
able (Replace  with  New  Unit) 

Product  is  Obsolete 

Software  May  Migrate  to 
New  Hardware  Generation* 

Product  is  Obsolete 

* MARKS  IMPORTANT  DIFFERENCES  IN  TERMINOLOGY 
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.This  sometimes  results  in  those  with  a hardware  background  under- 
estimating the  magnitude  and  importance  of  the  real  differences 
between  the  hardware  and  software  cycles. 

. In  software,  the  design/development  phase  is  of  critical  impor- 

tance; there  is  nothing  analogous  to  the  manufacturing  phase. 
(This  is  discussed  in  the  next  section  of  this  chapter.) 

. The  maintenance  phase  is  much  more  important  in  software,  not 

only  because  more  initial  "bugs"  may  appear,  but  also  because 
software  is  far  more  enhanceable  than  hardware.  (This  is 
discussed  in  the  next  chapter.) 

. Software  may  become  nonfunctional,  but  it  doesn't  "wear  out." 

In  principle,  software  is  eternal;  in  practice,  it  is  still  usually  so 
machine-  and  mission-dependent  that  it  usually  pays  to  discard 
rather  than  rework  it.  (This  may  change  in  the  future.) 

• However,  if  a 40/60  split  between  development  and  maintenance  is  assumed, 
along  with  a 10-year  software  life,  then  the  annual  maintenance  cost  is  equal 
to  15%  of  the  total  development  cost. 

This  percentage  is  in  line  with  current  maintenance  pricing  for 
commercial  software  packages. 

In  an  inflationary  environment  (either  generally  or  for  the  software 
sector  alone),  this  percentage  would  be  considerably  higher. 


C.  THE  SOFTWARE  DEVELOPMENT  PROCESS  AND  LIFE  CYCLE 


• The  overall  software  development  process  is  made  up  of  classic  steps: 
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Analysis. 


Design. 

Coding. 

Testing. 

This  is  shown  in  more  detail  in  Exhibit  IV-5. 

The  conceptual  content  is  identical  whether  new  development,  enhance- 
ments, or  error  corrections  are  involved. 

From  a life  cycle  planning  and  cost  standpoint,  there  are  two  phases: 

Development. 

. This  contains  30%  to  40%  of  costs. 

Maintenance. 

. This  includes  both  error  correction  and  enhancements. 

. It  contains  60%  to  70%  of  costs. 

These  percentages  are  informed  estimates  by  ECS  authorities. 

Unfortunately,  software  cost  data  is  very  soft  data.  Historic  data  is 
nonstandardized,  not  consistently  gathered  and  lacks  linkages  between 
project  event  reporting  and  contractual  cost  reporting.  (This  is 
discussed  in  more  detail  in  the  next  section  of  this  chapter.) 

Cost  estimating  tools  are  in  their  infancy. 
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EXHIBIT  IV-5 


ECS  SOFTWARE  PROCESS 


PROBLEMS/ 

REQUIREMENTS 


> 


ANALYSIS 


• DYNAMIC  SIMULATOR 

• HOT  MOCK  UP 


DETERMINE: 

FEASIBILITY 

SCOPE 

INTERFACES 

PERFORMANCE 

IMPACTS 


REQUIRE- 
MENTS 


► 


DESIG^jMEC^ANlzA^ON^- 


• DYNAMIC  SIMULATOR 


EQUATIONS 


PROGRAM 

FLOW 


TIMING 


R^ 


Rn 


R: 


— C:: 


Rx] 

Ry1 


ECS 

SUBSYSTEM 

DETAILED  DESIGN 


CODE  AND  DEBUG 


HOST  COMPUTER 


SOURCE 

CODE 


HOST 

COMPUTER 


UPDATED 

CODE 


O' 


BASELINE 


DOCUMENTATION 


CODE 


TEST  AND  VERIFICATION 


• DYNAMIC  SIMULATOR 

• HOT  MOCK  UP 


ECS  (TGT) 
COMPUTER 


ECS 


CONTROLLED 

INPUTS 


MEASURED 

OUTPUTS 


VERIFIED 

CODE 


► 


READY  FOR 
OPERATIONAL 
TESTING 
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Recent  studies  for  the  Air  Force  have  shown  that  cost  estimates  for  the 
average  software  projects  undertaken  for  them  were  60%  of  the  actual 
figure.  The  variances  were  nonlinear;  i.e.,  correction  factors  would  not 
help. 


. Different  software  environments  and  applications  make  the  same 
model  behave  differently,  sometimes  erratically. 

These  kinds  of  problems  are  not  because  of  a lack  of  estimating  models. 

See  Exhibit  IV-6  for  a description  of  some  of  the  most  discussed  models. 

. Note  that  these  models  are  algorithmic  ones,  whereby  a limited 
number  of  parameters  are  acted  on  by  a series  of  algorithms. 

. Models  now  focus  on  the  early  (development)  part  of  the  life 

cycle. 

• From  the  services'  standpoint  there  are  various  tradeoffs  associated  with 
developing  new  software  as  opposed  to  enhancing  existing  software.  One  view 
is  presented  in  Exhibit  IV-7. 

These  curves  should  only  be  taken  as  suggestive,  given  the  lack  of 

reliable  software  costing  data. 

. It  is  obviously  in  the  interests  of  those  who  would  maintain 

software  (and  make  a business  of  doing  so)  to  devise  method- 
ologies to  keep  the  logistics  cost  curve  from  rising. 


D.  ECS  SOFTWARE  ISSUES 


• The  major  issues  in  ECS  software  involve: 


- 43  - 


INPUT 


EXHIBIT  1V-6 

SELECTED  SOFTWARE  ESTIMATING  SOURCES 


• PRICE  Software  Lifecycle  Model  (RCA  PRICE  Systems) 

• Quantitative  Software  Management,  Inc.  (L.  Putnam) 

• Department  of  Defense  Micro  Estimating  Procedure 

• SOFCOST,  Grumman  Aerospace 

• Doty  Associates 

• Tecolote  Research,  Inc. 

• Boeing  Computer  Services  Model 

• TRW  Model  (Wolverton) 

• Aerospace  Corporation  Model 

• USAF,  Electronic  Systems  Command 
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EXHIBIT  I V-7 


* 


SOFTWARE  DEVELOPMENT  - MAINTENANCE  TRADEOFFS 


Logistics  costs  plus  development  costs 

““  “ ” Logistics  costs 

” Development  costs 

Source:  Air  Force  Analysis 
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.Measuring  its  characteristics  (especially  quality  and  costs). 

Improving  the  software  production  process  (i.e.,  ADA,  the  ADA  support 
environment,  and  the  more  generalized  DOD  software  initiative). 

• In  both  these  issues,  there  is  one  substantial  software  maintenance  component, 
although  it  is  often  glossed  over  in  the  literature. 

I . ECS  SOFTWARE  MEASUREMENT 

• ECS  quality  is  highly  variable.  Quality  is  defined  here  as: 

Correctness. 

Reliability. 

Maintainability. 

• There  is  no  commonly  accepted  definition  of  quality.  In  the  past,  ECS 
software  developers  focused,  at  most,  on  correctness.  Now  there  is  at  least 
lip  service  being  paid  to  reliability  and  maintainability. 

• There  are  also  few  commonly  accepted  ways  of  measuring  software  quality. 

This  is  in  large  part  because  of  the  lack  of  common  definitions. 

• There  is  an  almost  surreal  atmosphere  involved  in  attempts  to  identify  the 
amounts  spent  on  ECS  software. 

One  interviewee  in  a responsible  position  "gave  up"  in  trying  to 
estimate  the  Air  Force  software  budget  because  the  "numbers  were 
flakey." 


Numbers  obtained  ranged  from  $1.8  to  $8.0  billion. 
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A respondent,  in  response  to  an  INPUT  query  on  software  spending,  said 
that  INPUT  would  get  the  same  response  as  a three-star  general  had 
recently  received:  "We  don't  know." 

Another  respondent  was  very  concerned  about  many  aspects  of  ECS 
software,  but  said  that  quite  simply  they  had  "no  facts  to  warn  top 
management  with." 

• In  part  this  is  caused  by  definitional  problems. 

Sometimes  only  programming  costs  are  used.  On  the  over-the-horizon 
back  scatter  radar  program,  these  account  for  only  $40  million  out  of 
an  $80  million  program. 

. The  actual  software  development  costs  are  estimated  to  be  $800 
million. 

The  different  definitions  possible  can  lead  to  a range  of  $2  million  to 
$100  million,  as  on  the  F-15  upgrade. 

. The  higher  number  included  operational  flight  testing. 

• These  definitional  problems  are  greatly  compounded  by  the  many  opportunities 
for  ECS  software  dollars  to  be  misclassified. 

In  an  ideal  world,  hardware  and  software  development  dollars  would  be 
separated  from  software  maintenance  dollars;  see  the  cells  marked 
"OK"  in  Exhibit  IV-8. 

However,  there  are  many  opportunities  for  dollars  to  be  miscounted: 

. Software  may  be  lumped  together  with  hardware  in  whole  or 

part. 
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SOFTWARE  EXPENDITURE  ALLOCATIONS 
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Correct  Allocations 

Potential  Funding/Costing  Anomolies 


Original  funds  may  be  incompletely  specified. 


. Overrun  cost  may  be  allocated  to  "production"  rather  than 

software  development  or  enhancements. 

. The  relative  scarcity  of  O&M  funds  may  encourage  artificial 
classification  as  R&D. 

. Software  maintenance  funds,  especially  on  the  local  level,  may 
not  be  distinguished  from  other,  general  maintenance  funds. 

. Acceptance  testing  may  be  confused  with  normal  operations  (and 

vice  versa). 

. The  charging  of  the  expense  of  uniformed  personnel  may  be  very 

erratic. 

This  type  of  allocation  problem  was  cited  repeatedly  in  the  course  of 
interviews. 

These  allocation  problems  are  further  worsened  by  the  incomplete  linkage 

between  the  financial  tracking  systems  and  the  task  tracking  systems. 

Uniform  definitions  and  tracking  processes  are  now  being  developed 
under  the  sponsorship  of  the  Electronic  Systems  Command  which,  if 
successfully  implemented,  would  start  to  lay  a foundation  for  supplying 
reliable  data. 

. Numbers  would  not  be  produced,  however,  for  at  least  several 
years. 

SOFTWARE  PROCESS  IMPROVEMENTS 

There  is  certainly  a need  for  improvements  in  the  software  process. 
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Many  activities  are  duplicative. 


. There  are  few  opportunities  to  build  on  or  with  standard  modules 
or  software  libraries. 

Most  software  is  nonportable  owing  to  differences  in  one  or  more  of  the 

following: 

. Hardware. 

. Compilers. 

. Interfaces  and  protocols. 

. Data  definition. 

There  is,  in  addition,  often  a bias  against  "porting"  software. 

. This  is  often  justifiable  because  of  quality  problems. 

. ECS  software  is  caught  in  a vicious  circle:  because  everyone 

wastes  time  starting  from  ground  zero,  quality  is  indifferent; 
because  quality  is  indifferent  people  only  want  to  use  their  own 
software. 

. This  experience  is  similar  to  that  in  the  early  days  of  commer- 
cial data  processing  when  "software  exchanges"  did  not  live  up  to 
expectations. 

• There  is  a fairly  wide  consensus  that  software  improvement  must  take  place 
along  a wide  front  that  would  include: 

Productivity. 
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Standardized  output  units/standard  input  units. 


Maintainability. 

Reliability. 

Predictable  time  consumption/schedules. 

Lower  life  cycle  costs, 
a.  ADA 

The  implementation  of  the  ADA  language  will  certainly  be  very  helpful  in  at 
least  setting  the  stage  for  future  progress. 

As  shown  in  Exhibit  1 V-9,  ADA  certainly  has  distinct  theoretical 
advantages  over  other  languages,  scoring  373  out  of  a potential  394 
points. 

It  should  be  kept  in  mind  that  the  initial  coding  represents  only  a few  percent 
out  of  total  life  cycle  costs. 

Consequently,  it  is  premature,  at  the  least,  to  expect  the  "order  of 
magnitude"  improvements  that  some  ADA  proponents  predict. 

. Even  the  forecasted  software  savings  of  $20  billion  in  the  first 
10  years  of  use  is  only  a saving  of  5%  to  10%. 

Early  experiments  do,  however,  show  that  improvements  to  the  software 
process  could  lead  to  improvements  of  up  to  50%. 

Improvements  of  this  magnitude  are  dependent  on  the  ADA  support 
environment,  made  up  of: 
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EXHIBIT  I V-9 


ADA  COMPARISONS 


ABILITY 

FEATURE 

LANGUAGE  SCORE 

MAXIMUM 

POSSIBLE 

SCORE 

ADA 

FORTRAN 

J 73 

CMS 

Design 

1 . Reliability 

10 

5 

8 

5 

10 

Criteria 

2. Maintainability 

8 

5 

8 

6 

10 

3.  Efficiency 

5 

6 

6 

6 

9 

4.  Simplicity 

6 

6 

5 

2 

7 

5. Machine  Independence 

10 

9 

7 

5 

10 

6. Complete  Definition 

10 

4 

7 

8 

10 

General 

7. General  Syntax 

7 

6 

6 

4 

8 

Syntax 

8. Syntactic  Extensions 

5 

5 

3 

3 

5 

9.  Identifiers 

6 

2 

6 

3 

7 

1 0.  Literals 

8 

7 

8 

8 

8 

1 1 . Comments 

9 

8 

10 

10 

10 

Data 

12. Strong  Typing 

8 

1 

4 

3 

8 

T yping 

13. Type  Definitions 

8 

0 

5 

0 

8 

14. Numeric  Types 

9 

7 

10 

10 

10 

15. Numeric  Operations 

10 

10 

10 

8 

10 

1 6.  Enumeration  Types 

5 

0 

4 

0 

5 

17.  Boolean  Type 

5 

3 

5 

4 

5 

18. Character  Types 

8 

5 

8 

5 

8 

1 9.  Arrays 

10 

7 

8 

7 

10 

20.  Records 

8 

0 

5 

4 

8 

21 . 1 ndirect  T ypes 

5 

0 

3 

2 

5 

22. Bit  Strings 

5 

2 

5 

3 

5 

23.  Encapsulation 

5 

0 

2 

0 

5 

24.  Scoping 

10 

3 

9 

6 

10 

25.  Declarations 

10 

4 

10 

9 

10 

26.  Initial  Values 

5 

5 

4 

5 

5 

27.  Expressions 

10 

9 

9 

9 

10 

(Continued) 
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EXHIBIT  I V-9  (Cont.) 


ADA  COMPARISONS 


LANGUAGE  SCORE 

MAXIMUM 

ABILITY 

FEATURE 

ADA 

FORTRAN 

J 73 

CMS 

POSSIBLE 

SCORE 

Control 

28.  Control  Structures 

8 

6 

7 

6 

8 

29.  Conditional  Control 

10 

6 

10 

10 

10 

30.  Iterative  Control 

9 

4 

10 

6 

10 

31.  Explicit  Transfer 

8 

8 

7 

5 

8 

32.  Short  Circuiting 

5 

0 

5 

0 

5 

Functions 

33.  Procedures 

10 

9 

9 

7 

10 

1 / 0 

34.  Recursion 

5 

0 

5 

0 

5 

35.  Parameter  Passing 

10 

1 

9 

6 

10 

36.  Aliasing 

5 

0 

3 

4 

5 

37.  Low  Level  I/O 

5 

0 

4 

3 

5 

38.  Hi  Level  I/O 

8 

9 

0 

0 

9 

Real 

39.  Parallel  Processing 

4 

0 

0 

0 

5 

Time 

40.  Mutual  Exclusion 

5 

0 

0 

0 

5 

Processing 

41.  Scheduling 

4 

0 

0 

0 

5 

42.  Real  Time 

5 

0 

1 

1 

5 

43.  Interrupts 

5 

0 

3 

0 

5 

44.  Async.  Termination 

5 

0 

0 

0 

5 

Other 

45.  Exception  Handling 

9 

0 

5 

0 

10 

T echniques 

46.  Assertions 

3 

1 

1 

0 

5 

47.  Data  Representation 

8 

0 

6 

6 

8 

48.  Language  Interface 

10 

4 

10 

4 

10 

49.  Optimizations 

8 

1 

5 

1 

8 

50.  Libraries 

6 

2 

7 

8 

9 

51.  Separate  Transactions 

8 

7 

7 

8 

8 

52.  Generic  Definitions 

5 

0 

1 

0 

5 

T otals 

373 

177 

290 

210 

394 

INPUT 


Standard  operating  system  interface. 


. Standard  processes  and  documentation. 

. Standard  development  tools  (compiler,  debugger,  linker  loader, 

editor,  run  controller,  configuration  manager). 

• These  tools  would  then  have  to  be  further  extended  by  an  integrated  set  of 
techniques  with  a life  cycle  focus;  i.e.: 

Integrated  development. 

Functional  targets: 

. Feasibility  analysis. 

. Requirements  languages. 

. Specification  languages. 

. Simulation  and  prototyping. 

. Verification  and  testing  tools. 

• Many  of  the  benefits  from  the  ADA  support  environment  and  its  extensions 
need  not  necessarily  involve  ADA.  Most,  if  not  all,  of  these  tools  and 
techniques  have  been  in  existence  for  some  time. 

However,  ADA  may  serve  as  the  catalyst  and  rationale  for  their 
acceptance. 

b.  DOD  "Software  Initiative" 

• DOD  has  established  a fascinating  and  innovative  "software  initiative"  to 
continue  the  software  advances  that  ADA  will,  hopefully,  set  in  train. 
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These  "initiatives"  are  meant  to  build  on  what  now  exists,  partially  or  in 
concept.  They  are  divided  into  three  categories: 

Short-term  initiatives. 

. "Technology  transfer." 

. Implementable  in  under  four  years. 

Medium-term  initiatives. 

. Some  preliminary  work  on  solutions. 

. Four-  to  seven-year  horizon. 

Long-term  initiatives. 

. Problems  identified. 

. Greater  than  seven-year  horizon. 

Exhibits  IV- 1 0,  1V-II,  and  IV- 1 2 provide  more  information  on  the  types  of 
initiatives  proposed. 

These  vary  from  the  here  and  now  (e.g.,  programmer's  workstation)  to 
the  visionary  (e.g.,  voice  replaces  text). 

The  entire  ECS  community  will  benefit  from  this  work,  however,  even 
(or,  perhaps,  especially)  those  not  using  ADA. 

It  is  interesting  and  not  overly  heartening  that  only  two-thirds  of  the  experts 
interviewed  for  this  study  used  any  productivity  tools. 
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EXHIBIT  IV- 1 0 


SHORT-TERM  INITIATIVE  CANDIDATES 


• Technical 

- General  (Across  Lifecycle) 

. Integrated  Software  Support  Environment 

- ADA  Package  Sets  for  Common  Usage  Areas 

- System  Dictionary /Directory 
. Programmer  Workstation 

. Useful  Measures  of  Software  Quality 

- Concept /Feasibility 

. Rapid  Simulation 
Requirements 
. Rapid  Prototyping 
Design  and  Programming 
. Predicate  Approach 

- Testing 

. High  Confidence  Software  Testing 

- Operations 

. Impact  Analysis  of  Proposed  Change 

• Managerial 

Software  Technology-Compatible  Acquisition 

- Technology  Transfer 

• Personnel-Related 

- Superperformer  Competencies 
Improved  Education  About  Software 
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EXHIBIT  IV-11 


MEDIUM-TERM  INITIATIVE  CANDIDATES 


• Technical 

- General  (Across  Lifecycle) 

. Integrated  Software  Support  Environment 
- Sets  of  Tools  Covering  Entire  Lifecycle 
Multiple  Representations  of  Software 
. Configuration  Independence 
Requirements 

Application  Domain  Expertise 
. Data  Validation 
. Built-in  Testing 
. Forgiving  Systems 

- Design 

. Data  Flow 
. Exception  Handling 
Programming  (Predicate  Approach) 

. Transform  Software  to  Improve  Quality 

- Operations 

. Facilitating  System  Evolution 

(Impact  Analysis  of  Proposed  Change  Subsumed) 

• Managerial 

- Acquisition  Manager's  Support  System 

• Personnel-Related 

Programmer  Laboratory 

- Personnel  Independence 

Intensive  Advanced  Programmer  Training 

• Continuity-Related 

- Voice  Replaces  Text 

- Built-in  Training  and  Documentation 
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LONG-TERM  INITIATIVE  CANDIDATES 


• Technical 

- General  (Across  Lifecycle) 

Software  Engineer's  Support  System 
. Earliest  Possible  Detection  of  Errors 
Requirements 

. User  Oriented  Requirements  Interfaces 
. Complex  Knowledge-based  Systems 

- Design 

. Self-Interfacing  Software 
. Distributed  Functions  and  Resources 
Suitable  Communication  Interconnection 
Programming 

Formal  Verification  of  Large  Systems 

• Personnel-Related 

User  Programming 
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Of  those  that  did  use  such  existing  tools,  the  effects  on  productivity 
could  not  be  assessed  by  respondents. 

There  was  no  commonality  of  tool  use  or  assessment  methods. 


E.  REMAINING  ECS  PROBLEMS 


• There  are  many  interesting  and  probably  useful  ideas  afloat  in  the  ECS 
software  world.  In  the  future,  these  will  have  considerable  beneficial  effect 
on  new  ECS  development. 

However,  there  will  be  no  ADA-based  systems  operational  until  the  late 
1980s. 

In  the  meantime,  there  will  have  been  literally  hundreds  of  ECS  systems 
produced. 

• No  respondent  had  any  easy  answers  on  what  would  happen  to  these  systems. 

A few  spoke  vaguely  of  converting  to  ADA. 

. That  would  usually  not  be  feasible  because  of  retesting,  etc. 

The  reality  is  that,  as  the  experts  interviewed  agreed,  the  average  life 
span  of  ECS  software  is  10  to  20  years. 

Mixed  ADA  and  non-ADA  development/enhancements  will  prove  diffi- 
cult. In  commenting  on  the  most  widely  used  current  language,  CMS, 
one  authority  stated  that  the  "completely  different  approach  to  multi- 
tasking makes  mixed  CMS/ADA  operational  software  difficult  or 
impossible." 
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So,  not  for  the  first  time,  interest  in  development  takes  precedence 
over  maintenance. 

• ADA  will  make  it  theoretically  possible  to  deal  with  interoperability  issues. 

ADA  will  not,  however,  make  the  logical  and  mission  problems  of 
interoperability  any  easier  to  deal  with,  merely  more  visible. 

• Exhibit  IV- 1 3 illustrates  the  dilemma  that  several  respondents  described: 
while  ECS  software  capabilities  will  increase  significantly  in  the  1980s,  no 
breakthrough  is  expected.  The  requirements  to  be  met  will,  however,  continue 
to  increase  in  intensity  and  at  a greater  rate  than  capabilities  to  solve  them. 
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EXHIBIT  IV-13 


SOFTWARE  DILEMMA 


«* TIME ► 
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V ECS  SOFTWARE  MAINTENANCE 


V 


ECS  SOFTWARE  MAINTENANCE 


A.  TYPES  OF  SOFTWARE  MAINTENANCE 


• Most  ECS  software  "maintenance"  actually  consists  of  improvements  or 
enhancements.  Such  enhancements  arise  from  three  basic  causes: 

Introduction  of  a multi-use  system/subsystem;  e.g.: 

. Pave  tack. 

. Issue:  Integration  with  "host"  ECS. 

Changes  in  mission/doctrine;  e.g.: 

. F-16:  Both  air/air  and  air/ground. 

Product  improvements,  foreseen  and  unforeseen;  e.g.: 

. Microprocessor  size/performance. 

• Only  about  10%  to  20%  of  software  maintenance  work  is  fixing  errors;  this 
percentage  is  in  line  with  experience  in  the  government  ADP  world  and  in 
private  corporations. 
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• Exhibit  V—  I shows  the  range  of  the  improvements  in  one  particular  weapon 
system. 

Equally  significant  is  that  such  improvements  occur  incrementally  over 
a period  of  time.  Exhibit  V-2  shows  the  350  changes  to  the  F-lll 
family's  operational  flight  programs. 

• Maintenance  can  be  very  expensive.  According  to  one  Air  Force  study,  the 
cost  per  line  of  new  code  averaged  $75,  while  maintenance  could  cost  as  much 
as  $4,000  per  line  of  code. 

This  is  because  the  later  in  the  life  cycle  that  a program  is  changed  the 
more  expensive  the  change  becomes,  as  shown  in  Exhibit  V-3. 

Not  only  do  previous  steps  have  to  be  retraced,  but  sometimes  the 
design  of  the  system  itself  will  no  longer  be  appropriate  for  the  newly 
required  function. 

• A special  factor  in  many  ECS  systems  is  that  there  is  only  a limited  amount  of 
physical  space,  hence,  processing  power  and  storage,  available.  This  means 
that  later  enhancements  are,  inevitably,  trying  to  put  10  pounds  in  a 5-pound 
bag,  as  shown  in  Exhibit  V-4. 

B.  THE  SOFTWARE  MAINTENANCE  ENVIRONMENT 


• The  general  software  maintenance  process  is  similar  in  principle  to  the 
software  development  process  in  terms  of  the  sequence  of  the  tasks  and  the 
general  skills  required. 

• However,  there  are  significant  differences  between  software  development  and 
maintenance  activities. 
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EXHIBIT  V-l 


F-111  ECS  CHANCES 


• Significant  Improvements  in  Navigation  and 
Weapon  Delivery 

- Bombing  Accuracy  Improvements 

- SRAM  Alternate  Launch  Mode 

- Wind  Vector  Fix  and  Heading  Fix  Modes 

- Moving  Target  Detect  Mode 

- Height  to  Target  Mode 

- Improved  Beacon  Bombing 
Improved /Modified /New  Ballistics 

- Expanded  Offset  Aimpoint  Capability 
Expanded  Steer  Points 

- Short  Bomb  Fix  F-111F/Pave  Tack 

- Ground  Navigate  Mode 

- Fix  Quality  Mode 
Improved  Self  Test /Bite 

Source:  1981  Naecon,  p.  132 
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EXHIBIT  V-2 


ii 


F-111  OPERATIONAL  FLIGHT  PROGRAM  CHANGES 


! AIRCRAFT 

RELEASED 

VERSIONS 

NUMBER  OF 
CHANGES 

DATE 

FB-111  A 

FB-12 

15 

9/74 

FB-13 

30 

1 / 7 6 

FB-15 

33 

1 / 7 8 

FB-16 

22 

7/79 

FB-17 

19 

11/80 

F-111D 

D-1 6 

21 

9/75 

D-17 

32 

11/76 

D-1  8 

20 

7/77 

D-20 

53 

10/80 

F-111F 

F-1 1 

60 

11/76 

F-1 2 

46 

6/78 

F-12A 
F-1  3 

(Pave  Tack 
1 mplementation) 

3 

9/79 

10/80 

Source:  1981  NAECON,  p.  132 
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SOFTWARE  MODIFICATION  COSTS 
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EXHIBIT  V-4 


CAPACITY  LIMITATIONS  EFFECTS  ON  MAINTENANCE  COSTS 


0 25  50  75  100% 

Utilization  of  Speed  and  Memory  Capacity  (Percent) 


Source:  Texas  Instruments 
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, There  is  a common  misconception  that  software  maintenance  is  less 
demanding  and  demands  fewer  skills  than  does  software  development. 

This  is  not  true;  if  anything,  software  maintenance  may  be  more  demanding  in 
general  than  development;  e.g.: 

Support  is  often  necessary  for  multiple  versions  of  one  weapons  system. 

Unforeseen  new  requirements  must  be  coped  with. 

There  are  often  severe  capacity  and  performance  constraints. 

The  most  important  software  maintenance  activities  will  be  carried  out 
in  a potential  war  or  crisis  environment. 

While  the  requirements  are  often  more  demanding  than  in  the  development 
area,  the  resources  to  carry  them  out  are  often  inferior. 

Software  maintainers  must  work  with  obsolete  languages;  often  these 
languages  were  abandoned  with  good  reason. 

Documentation  is  often  poor,  sometimes  non-existent. 

Productivity  tools  are  even  less  advanced  than  in  the  development  area. 

ECS  software  often  has  a long  maintenance  "tail."  In  the  E-3,  for  example: 

There  are  only  150,000  lines  of  code  at  squadron  level. 

However,  there  are  2,700,000  lines  overall.  There  are  multiple  lan- 
guages, operating  systems,  and  compilers. 

As  ECSs  come  out  of  the  pipeline,  the  maintenance  problems  become  more 
apparent  and  more  of  a burden.  Some  of  the  problems  are: 
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Poorly  defined  functional  and  interface  requirements. 


Lack  of  modularity. 

Machine-oriented  languages. 

Poor  maintainability  design. 

Lack  of  hardware  standardization. 

Inadequate  documentation. 

Marginal  training. 

• Examining  these  kinds  of  problems,  the  Army  stated  in  its  ECS  software 
support  plan: 

"It  is  doubtful  if  the  Army  can  provide  adequate  support  in  wartime  or 
crisis." 

• These  considerations  have  made  the  services  far  more  aware  of  the  impor- 
tance of  ECS  software  support. 

There  have  been  recent  plans  by  both  the  Air  Force  and  Army  to 
address  these  problems  (these  are  addressed  in  more  detail  later  in  this 
chapter). 

• The  experts  interviewed  viewed  current  development  methodologies  as  not 
supporting  maintainability  or  reducing  costs. 

They  did  not  see  the  cost  situation  improving. 

They  believed  that  maintainability  might  improve  as  new  techniques 
took  hold. 
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C.  STANDARDS  AND  MAINTENANCE 


• Both  hardware  and  software  standards  (or  the  lack  thereof)  are  having  and  will 
continue  to  have  a significant  impact  on  software  maintenance. 

The  future  impact  of  ADA  has  already  been  commented  on. 

• In  theory,  there  is  already  considerable  standardization  in  both  hardware  Gnd 
software,  as  shown  in  Exhibit  V-5.  However,  the  reality  is  far  less  attractive. 

The  Air  Force  has  over  400  languages  and  dialects  to  support. 

The  Army  has  almost  60  different  CPUs  made  by  at  least  29  manu- 
facturers, as  shown  in  Exhibit  V-6. 

. The  Army  has  24  assemblers  and  10  high-order  languages  to 
support,  as  shown  in  Exhibits  V-7  and  V-8. 

The  Army  could  and  should  have  learned  from  the  Air  Forceps  experi- 
ence, since  most  of  its  systems  are  not  yet  operational.  However,  it  did 
not. 

• The  Navy,  on  the  other  hand,  has  taken  a very  standardized  approach. 

Most  of  its  ECS  systems  run  off  a common  set  of  computers,  as  shown 
in  Exhibits  V-9  and  V-10,  and  with  a common  language,  CMS. 

• The  Navy  has  probably  gone  too  far  in  the  opposite  direction  with,  in  the  words 
of  one  Navy  respondent,  an  "old-fashioned"  hardware  philosophy. 

Given  the  five-  to  seven-year  development  period  for  its  proprietary 
hardware  systems,  these  systems  are  obsolete  as  soon  as  they  are 
fielded. 
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EXHIBIT  V-5 


DOD  HARDWARE  AND  SOFTWARE  INTERIM  STANDARDS 


INTERIM 

DOD-APPROVED  HIGH 
ORDER  LANGUAGES 

INTERIM  COMPUTER  HARDWARE 

AN/ 

GYK-12 

AN/ 

UYS-1 

AN/ 

UYK-7 

AN/ 

AYK-14 

AN/ 

UYK-20 

MIL-STK 

1750 

MILITARY 

COMPUTER 

FAMILY 

M11-STD 

1862 

TACPOL 

X 

CMS-12 

X 

X 

X 

SPL-1 

JOVIAL  J 3 

JOVIAL  J 73 

X 

X 

COBOL 

FORTRAN 

X 

X 

X 

Common  DOD  HOL  (ADA) 

X 

X 

X 

X 

X 

X 

INF 
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ARMY  HARDWARE 


MANUFACTURER 

CPU  NAME 

1.  Bendix 

1.  BDX-930 

2.  BDX-820 

2.  Burroughs 

3.  B 3500 

4.  D 84 

3.  Control  Data  Corporation 

5.  CDC  469 

6.  AN/UYK-23 

7.  AN/AYK-14 

4.  Data  General 

8.  Eclipse  S/130 

9.  Nova  800 

10.  Nova  1200 

5.  DEC 

11.  LSI  - 11/03 

12.  PDP  11/34 

13.  PDP  11/70 

14.  VAX  11/780 

6.  General  Motors 

15.  DELCO  M-362F-1 

7.  GTE 

16.  GTE  2500 

8.  Hewlett-Packard 

17.  HP  2100S 

18.  HP  2108 

19.  HP  2113 

20.  HP  9825A 

21.  HP  1000 

9.  Honeywell 

22.  Level  6 

10.  Hughes  Aircraft  Company 

23.  HMP  3637 

24.  HMP  1160 

11.  IBM 

25.  360/370  series 

12.  INTERSIL 

26.  IM  6100 

13.  Intel 

27.  8080A 

28.  8085 

29.  8748 

14.  ITT 

— 

15.  Litton  Industries 

30.  AN/GYK-12 

31.  LC-728 

(Continued) 
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EXHIBIT  V-6  (Cont.) 


ARMY  HARDWARE 


MANUFACTURER 


CPU  NAME 


16.  Magnavox  Display  Systems 


17.  MODCOMP 

18.  Motorola 

19.  NCR 

20.  Northern  Electric 

21.  Norden 

22.  Perkin-Elmer 

23.  RCA 

24.  Raytheon  Company 

25.  ROLM 

26.  Singer  - Kearfoot 

27.  Texas  Instruments 

28.  Teledyne 

29.  Univac 

30.  Unidentified 


32.  CP-1 275(  )/U 

33.  MAXAL 

34.  FADAC 

35.  MODCOMP  IV 

36.  6800 

37.  NCR  500 


38.  AN/GYK-29 

39.  AN/UYK-42 

40.  Interdata  6/T6 

41.  Interdata  8/32C 

42.  CDP-1802 

43.  Special 

44.  AN/UYK-19  (V) 

45.  UYK-34 

46.  SKC3020/SKC3120 

47.  CP-1  093/TYQ 

48.  TI-9900 

49.  SBP-9900 

50.  T I 546LS  181 

51.  TDY-43 

52.  AN/UYK-7 

53.  AN/UYK-20 

54.  U / 1 600 

55.  1005 

56.  AN/UYK-11 

57.  AMD  2901 

58.  2870 

59.  CP  1393 


EXHIBIT  V-7 


ARMY  ECS  ASSEMBLER  LANGUAGES 


OBJECT /TARGET 
CPU 

NUMBER  OF 
ECS  ON 
WHICH  USED 

1.  Bendix  820 

2 

2.  B 3500 

1 

3.  D 84 

1 

4.  AN/UYK-23 

1 

5.  PDP-11/70 

1 

6.  GTE  2500 

1 

7.  HP  2113 

1 

8.  HP  9825A 

1 

9.  HMP  3637 

2 

10.  IM  6100 

1 

11.  AN/GYK-12 

5 

12.  LC  728 

1 

13.  AN/UYK-42 

1 

14.  1 6/16 

1 

15.  1 8/32C 

1 

16.  Raytheon  Special 

1 

17.  AN/UYK-19 

13 

18.  SKC-3020 

1 

19.  AN/UYK-7 

1 

20.  AN/UYK-20 

2 

21.  AN/UYK-11 

1 

22.  2870 

1 

23.  CP  1393 

1 

24.  SIR 

1 
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EXHIBIT  V-8 

ARMY  HIGH  ORDER  ECS  LANGUAGES 


LANGUAGE 

OBJECT  /TARGET 
CPU 

NUMBER 
OF  BASS 
ON  WHICH 
USED 

CPU  NAME 
REFERENCE 
FROM 

TABLE  V-6 

COMMENTS 

1.  FORTRAN 

Bendix  820 

1 

2 

PDP  11/70 

3 

13 

VAX  11/780 

1 

14 

Variant  or 

HP  2100 

1 

17 

dialect 

HP  2108 

1 

18 

unspecified 

HP  2113 

4 

19 

HMP  1160 

1 

24 

AN  /GYK-12 

3 

30 

(I , II, 

1 8/32C 

1 

41 

III,  IV,  or 

AN/UYK-19 

2 

44 

V) 

AN/UYK-34 

1 

45 

Unidentified 

3 

- 

2.  TACPOL 

AN  /GYK-12 

1 

30 

AN/UYK-19 

1 

44 

3.  PASCAL 

VAX  11/780 

1 

14 

AN/UYK-42 

1 

39 

AN/UYK-20 

1 

53 

4.  EUCLID 

AN  /UYK-42 

1 

39 

5.  CMS-2 

Nova  800 

1 

9 

Version 

Nova  1200 

1 

10 

unspecified 

AN/UYK-7 

2 

52 

AN/UYK-20 

1 

53 

(Q  or  Y) 

6.  JOVIAL 

Bendix  820 

1 

2 

PDP  11/70 

1 

13 

Version 

HP  2113 

1 

19 

unspecified 

MODCOMP  IV 

1 

35 

Raytheon  Special 

1 

43 

(J73) 

Unspecified 

2 

- 

7.  ATLAS-E 

Bendix  820 

1 

2 

PDP  11/70 

1 

13 

HP  2113 

1 

19 

HP  1000 

1 

21 

Eclipse  S/130 

1 

8 

Unidentified 

1 

- 

8.  PL/M 

Unspecified 

1 

— 

Micro 

9.  COBOL 

Honeywell  Lev  6 

1 

22 

Level 

unspecified 

10.  MOTEL 

HP  2113 

1 

19 

NAVY  - AN/UYK-7  APPLICATIONS 


CO 

o 

CO 

m 

CO 

CO 

o 

i 

1 

CD 

r-> 

CD 

a 

a 

D 

a 

a 

z 

Z 

CO 

CO 

CQ 

CO 

CO 

CO 

CO 

co 

CL 


u 
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U 

I—  ^ 
2 Q- 
LU  < 
Q 

O' 

H 


rN 


CO 


INPUT 

YFA2 


PMS  408 

Design  and  Principal  Development 
Agency  for  Department  of  Defense 


EXHIBIT  V-10 


AN/AYK-14  (V)  USER  SYSTEMS 


F-1 8 

LAMPS  MK  III 
AV-8B 
EP-3 
SOTAS 
ACLS 
ALWT 
E2-C 
EA-6B 
P-3C 

FIREBRAND 

DASS 

ISIS 
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, . In  addition,  the  Navy  becomes  locked  into  a very  small  set  of 

vendors. 

• On  the  software  side,  its  standard  language  CMS-2  has  similar  problems.  In 
the  words  of  one  Naval  officer: 

"PL- 1 took  the  best  from  COBOL,  FORTRAN,  and  ALGOL;  CMS-2  got 
what  was  left  over." 

• The  net  result  of  the  Navy  approach  is  summed  up  by  a major  contractor: 

"The  Navy  requirement  is  to  use  an  unavailable  computer  (AN/UYK-44), 
an  untested  executive  (SDEX/M),  an  untested  compiler  (CMS-2M),  and 
unavailable  peripheral  hardware." 

• Given  the  long  life  of  ECS  software,  the  overall  situation  from  a software 
maintenance  standpoint  should  not  begin  to  change  appreciably  for  at  least  10 
years. 


D.  THE  ECS  SOFTWARE  MAINTENANCE  PROCESS 

• Software  maintenance  in  an  ECS  environment  is  unavoidably  complex.  The 
Army's  planned  approach,  as  shown  in  Exhibit  V-l  I,  is  a good  conceptual 
integration  of  the  technical-  and  mission-oriented  aspects  of  ECS  software 
maintenance. 

Even  this  present  Army  plan  does  not  deal  with  supporting  such  things 
as: 


Automatic  Test  Equipment  (ATE)  management. 
Microprocessor  support. 
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EXHIBIT  V-11 


ARMY  ECS  SOFTWARE  SUPPORT  MODEL  (SIMPLIFIED) 


, . Support  standardization  (across  support  centers). 

. Army-wide  systems  (i.e.,  above  corps). 

The  main  problem  that  exists  with  the  Army  and,  to  some  degree  the  Air 
Force,  is  the  "plethora  of  regulations,  instructions,  and  directives"  (quote  from 
Army  ECS  support  plan).  In  the  Army's  case,  this  includes: 

Army  command  and  control  master  plan. 

Integrated  tactical  communications  system. 

Army  battlefield  interface  concept. 

Battlefield  automated  management  plan. 

Battlefield  automation  interoperability  system  engineering  management 
plan. 

Joint  interoperability  tactical  command  and  control  system  program. 

The  Air  Force  is  going  through  a similar,  far  more  extensive,  ECS  software 
maintenance  planning  cycle  (see  Appendix  G,  Key  Documents). 

The  Navy  does  not  have  a software  support  approach  as  such. 

It  is  fair  to  say  that  all  three  of  the  services  are  groping  toward  a process  that 
will  enable  them  to  maintain  their  ECS  software  effectively.  The  main- 
tenance process  is  tied  in  very  closely  with  organizational  arrangements, 
especially  in  the  eyes  of  the  services.  These  arrangements  are  discussed  in  the 
next  section. 
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ECS  SOFTWARE  MAINTENANCE  ORGANIZATION 


• The  services  have  taken  different  approaches  to  organizing  the  ECS  software 
maintenance  function,  as  shown  in  Exhibit  V-12. 

Only  the  Air  Force  has  achieved  a reasonably  complete  division 
between  the  development  and  support  organizations.  (Note:  The 

military  usually  uses  the  term  "support"  rather  than  "maintenance.") 

. This  approach  is  logical,  well  in  place,  and  appears  to  be  working 
well. 

Both  the  Army  and  Navy  have  united  development  and  support  organi- 
zations. 

. In  the  Navy,  these  are  unified  down  to  quite  a low  organizational 

level. 

The  Army  separates  development  and  support  in  theory.  In  practice, 
though,  the  functional  commands  take  a leading  role,  often  weighted 
toward  the  development  side. 

• Exhibit  V- 1 3 shows  the  Air  Force  ECS  software  support  structure. 

Most  systems  are  supported  at  air  logistics  centers  (ALC). 

. In  the  past,  a particular  center  has  tended  to  specialize  in 

particular  aircraft  or  other  systems. 

• Exhibit  V-14  shows  the  Navy  ECS  software  support  organization. 

These  centers  are  organized  by  functional  system  and  handle  both 
development  and  maintenance  work. 
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EXHIBIT  V- 1 2 


ECS  SOFTWARE  DEVELOPMENT /MAI  NTENANCE  APPROACHES 


e Air  Force 

Development:  Systems  Command  (Most) 

Support:  Logistics  Command  (Most) 

User  Commands  (Some) 

© Navy 

Development  and  Support:  Material  Command 

Development  and  Support: 

. Support  Software:  Material  Command 

. Application  Software:  Separate  Functional 

Commands 

• Army 

- Development  and  Support  Policy:  Development 

And  Readiness  Command  (DARCOM) 

Development:  Functional  R&D  Commands 

- Support:  Post-Deployment  Software  Support 

(PDSS)  Centers 
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EXHIBIT  V- 1 3 


AIR  FORCE  ECS  DEVELOPMENT  AND  SUPPORT  STRUCTURE 


Product  Acceptance 

Air  Force  Test 
And  Evaluation 
Center 

(AFTEC) 

Headquarters 

(USAF) 

Product  Development  Product  Use 


Implementing 

Command 

Using 

Systems 

Command 

Commands 

Product  Support 


Suppo  rting 
Command 

Logistics 

Command 


Product  Divisions 

• Aeronautical  System  Division  9 Tactical* 

(Wright  Paterson  AFB) 

9 Strategic* 

• Electronic  Systems  Division 

(Hanscom  AFB)  • Air  Defense* 

• Space  S Missile  Systems  Org.*  c Airlift* 

(Los  Angeles  AFS) 


Air  Logistics  Center 

• Warner  Robins,  GA 
(Robins  AFB) 

• Sacramento,  CA 
(McClellan  AFB) 

• Ogden,  UT 
(Hill  AFB) 


• Laboratories 

• Test  Ranges 


Oklahoma  City,  OK 
(Tinker  AFB) 


* ALSO  SUPPORTS 


San  Antonio,  TX 
(Kelly  AFB) 


EXHIBIT  V- 1 4 
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NAVY  ECS  SOFTWARE  SUPPORT  ORGANIZATION 


LOCATION 

RESPONSIBILITY 

San  Diego 

Aircraft 

Dam  Neck,  VA 

Ships 

Washington,  DC 

Command  and  Control 

Philadelphia 

Strategic  Intelligence 

Camp  Pendleton,  CA 

All  Marine  Systems 
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Exhibit  V—  1 5 shows  the  Army  ECS  support  center  organization. 

This  is  a complex  organization  that  is  only  partly  operational.  In 
coming  years  there  will  be  a significant  number  of  systems  to  support, 
as  shown  in  Exhibit  V-16. 

The  services  software  support  approaches  seem  weak. 

The  Air  Force  approach  is  best,  but  is  obsolescent.  Separate  centers 
for  individual  systems  have  alv/ays  been  partially  duplicative.  In  an  age 
of  increasing  interoperability,  they  are  now  becoming  less  functional. 
The  Air  Force  recognizes  this  and  is  revising  its  plan. 

The  Navy  has  no  plan.  It  has  been  helped  to  a degree  by  standardiza- 
tion. 

The  Army's  approach  is  disjointed  and  appears  politically  driven  to  an 
extent. 

The  overall  DOD  approach  is  unfocused. 

. The  draft  DOD  regulation  on  "Management  of  Computer 
Resources  in  Defense  (ECS)  Systems"  (October  1981)  devotes 
only  5%  of  its  text  to  software  maintenance. 

. What  is  included  is  vague  and  nonspecific. 

The  Air  Force's  ECS  support  long-term  plan  does  not  pretend  to  have  all  of  the 
answers,  but  is  by  far  the  most  complete  and  thoughtful  one.  It  reviews  the 
status  of  current  systems  and  proposes  both  administrative  and  programmatic 
changes. 


Administratively,  the  Air  Force  will: 
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Vi 


ARMY  SOFTWARE  SUPPORT  CENTERS 


RESPONSIBLE  COMMANDS 

LOCATION 

ARRADCOM  (Armament) 

Picantinny  Arsenal 

CORADCOM  (Communication) 

Fort  Monmouth 

CORADCOM  (Communication) 

Fort  Leavenworth 

CSC  (ADP) 

Fort  Belvoir 

CSC  (ADP) 

Fort  Lee 

MICOM  (Missiles) 

Fort  Bliss 

CORADCOM  (Communication) 

Fort  Sill 

ERADCOM  (Electronics) 

Fort  Huachuca 

ERA  DCOM  (Electronics  / Intelligence) 

Fort  Monmouth 

MICOM  (Missiles) 

Redstone  Arsenal 

AVRADOM  (Aviation) 

Fort  Monmouth 
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EXHIBIT  V-16 


ARMY  ECS 


DEVELOPMENT 

COMMAND 

NUMBER  OF 
SYSTEMS 

CATEGORY* 

ONE 

TWO 

THREE 

ARRADCOM 

8 

0 

2 

6 

AVRADCOM 

11 

0 

0 

11 

CORADCOM 

34 

4 

14 

16 

ERADCOM 

29 

1 

8 

20 

Ml  COM 

6 

0 

2 

4 

OTHER 

3 

1 

1 

1 

T otal 

91 

6 

27 

58 

^Category : 

1.  Large  Systems,  Change  Expected 

2.  Small  Systems,  Change  Expected  or  Large  Stable  Systems 

3.  Small  Stable  Systems. 

(For  details,  see  Appendix  H) 
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Matrix  hardware  and  software  engineers. 


. Establish  better  career  paths. 

Programmatically,  the  following  improvements  will  be  made: 

. Support  will  be  automated  and  standardized. 

. Support  centers  will  support  multiple  systems  and  functions. 

. The  centers  themselves  will  be  closely  tied  together  by  tele- 
communications networks  to  provide  mutual  support. 

. Special  attention  will  be  given  to  readiness  support  for 
Electronic  Warfare  (EW),  many  details  of  which  are  in  the 
classified  section  of  the  report. 

Even  the  Air  Force  plan  still  envisions  a dispersion  of  support  by  geography 
and  weapons  systems. 

While  some  weapons  systems  specialization  is  unavoidable  and  often 
desirable,  much  current  dispersion  is  historical  and,  in  the  Army’s  case, 
political. 

This  dispersion  was  reasonable,  or  at  the  least,  defensible  in  the  1970s. 
However,  it  will  cause  problems  in  the  1980s  and  1990s  because: 

There  will  be  duplication  of  effort. 

It  may  interfere  with  improved  interoperability. 

It  will  waste  scarce  personnel  resources. 
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F.  SOFTWARE  MAINTENANCE  TRENDS 


• There  are  forces  which  could  blunt  or  reduce  the  increase  in  ECS  software 
maintenance.  These  are  listed  in  Exhibit  V-17. 

By  and  large,  these  represent  hopes,  rather  than  certainties. 

. In  any  event,  there  will  be  little  effect  on  systems  deployed  or  in 

the  pipeline. 

• Exhibit  V- 1 8 shows  a similar  list  of  events  which  could  increase  the  need  for 
ECS  software  maintenance. 

Most  of  these  are  quite  likely  to  occur. 

• On  balance,  then,  the  forces  impelling  the  growth  of  ECS  software  main- 
tenance are  quite  strong. 

• Quantifying  the  growth  of  software  maintenance  is  difficult,  especially  since 
the  services  themselves  are  unsure  of  the  exact  amounts  of  their  current 
software  spending,  not  to  mention  trying  to  divide  it  between  development  and 
maintenance.  The  factors  behind  this  difficulty  were  discussed  in  Chapter  IV. 

These  number  problems  explain  why  the  services  were  so  willing  to 

accept  the  EIA  data. 

• One  way  of  estimating  the  amount  of  current  and  future  maintenance  is  to 
take  the  EIA  total  software  estimates  and  divide  them  into  development  and 
maintenance. 

The  average  for  most  data  processing  installations  is  approximately 

50%  of  budgets  spent  on  new  development  and  50%  on  maintenance. 
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EXHIBIT  V-1 7 


EVENTS  WHICH  WILL  DECREASE 
ECS  SOFTWARE  SUPPORT  REQUIREMENTS 


• More  complete  original  requirements 
specifications 

• Systems  commonality 

- Hardware  (e.g.,  MIL  STD  1750  A) 

- Software  (e.g»,  ADA) 

Reusable  software  modules 

• Good,  standard  documentation 

• Correct,  structured  software 

• Better  testability 

• Service  organizational  improvements 

• Stabilized  international  situation 
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EXHIBIT  V-1  8 


EVENTS  WHICH  WILL  INCREASE 
ECS  SOFTWARE  SUPPORT  REQUIREMENTS 


• Switching  of  functions  from  hardware  to  software, 
e ECS  functional  proliferation 

• Unforeseeable  changes  in  system  requirements. 

• Technical  advances  which  must  be  retrofitted  into 
systems . 

• Poor  current  systems:  Current  or  in  the  pipeline 

• Unstable/tense  international  situation. 
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„ . ECS  software  maintenance  is  probably  less  than  this  because  so 
many  new  systems  are  still  under  development.  Certainly,  30% 
is  the  minimum  amount,  with  40%  the  most  likely. 

Looking  to  the  future,  ECS  software  maintenance  will  certainly  exceed 
the  average,  since: 

. ECS  will  be  coming  on  stream  in  the  1980s  in  large  numbers. 

. The  ECS  software  life  span  will  be  much  longer  than  that  of 

ordinary  software. 

. The  need  for  modification  will  be  much  greater. 

Given  these  developments,  it  would  not  be  at  all  surprising  to  see  ECS 
software  maintenance  as  high  as  70%  of  the  total  ECS  software 
spending  in  the  1990s.  Certainly,  it  would  be  at  least  half. 

Given  this  scenario,  it  is  then  possible  to  compute  the  high,  low,  and  most 
likely  spending  on  ECS  software  maintenance,  using  the  EIA  data  from  Exhibit 
111-6. 


The  effects  of  these  different  assumptions  are  shown  in  Exhibit  V- 1 9. 

Taking  these  most  likely  figures,  and  assuming  an  evenly  distributed  growth  of 
maintenance  from  40%  to  60%,  produces  the  growth  rate  shown  in  Exhibit  V- 
20. 


Note  that,  at  even  a 50%  split,  the  market  is  an  extremely  large  one. 
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EXHIBIT  V-19 


RANGES  OF  ECS  SOFTWARE  MAINTENANCE  SPENDING 

(EXCLUDES  CLASSIFIED) 


1980 

MAINTENANCE 

1990 

MAINTENANCE 

RANGE 

($  billions) 

(percent) 

($  billions) 

(percent) 

Low 

$0.  9 

30% 

$16.0 

o\° 

o 

in 

Most  Likely 

1.1 

40 

19.  3 

60 

High 

1.4 

50 

22.  5 

70 

Note:  Dollars  are  "then  year" 
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ECS  SOFTWARE:  DEVELOPMENT  VERSUS  MAINTENANCE 


$38 

36 

34 

32 

30 

28 

26 

24 

22 

g 20 

2 18 

_J 

- 16 

co 

**  14 


TOTAL 


SOFTWARE 

MAINTENANCE 


SOFTWARE 
1 DEVELOPMENT 


1980 

1981 

1982 

1983 

1984 

1985 

1986 

1987 

1988 

1989 

1990 

$ BILLION 
(“THEN  YEAR” 
DOLLARS) 

1980 

1981 

1982 

1983 

1984 

1985 

1986 

1987 

1988 

1989 

1990 

Software 

Development 

$1.7 

$2.6 

$3.2 

$3.9 

$4.7 

$5.6 

$6.7 

$7.9 

$9.3 

$11.0 

$12.8 

Software 

Maintenance 

1.1 

1.9 

2.4 

3.3 

4.3 

5.6 

7.2 

9.3 

11.9 

15.2 

19.3 

Total 

$2.8 

$4.5 

$5.6 

$7.2 

$9.0 

$11.2 

$13.9 

$17.2 

$21.2 

$26.2 

$32.1 

SOURCE:  INPUT  FORECASTS 
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VI  ECS  SOFTWARE  MAINTENANCE  BUSINESS  ISSUES 


VI  ECS  SOFTWARE  MAINTENANCE  BUSINESS  ISSUES 


• In  considering  entry  into  the  ECS  software  maintenance  business,  several 
issues  must  be  considered: 

What  is  the  real  and  perceived  need  for  software  maintenance  con- 
tractors from  the  services'  viewpoint? 

How  do  contractors  perceive  software  maintenance? 

What  is  the  competitive  environment? 

What  are  the  choices  in  organizing  an  ECS  software  maintenance 
undertaking? 

A.  THE  NEED  FOR  SOFTWARE  MAINTENANCE  CONTRACTORS 


I.  AMOUNT  OF  CONTRACTOR  USE 

• Currently,  about  half  of  software  maintenance  is  being  carried  out  by 
contractors. 

The  Navy  is  using  about  60%  contractors. 
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, Air  Force  Logistics  Command  has  spent  about  $80  million  on  con- 
tractors and  $90  million  on  organic  (in-house)  ECS  software  main- 
tenance in  1980. 

. The  contractor  portion  is  growing  over  25%  annually. 

The  Army  still  has  many  of  its  ECS  systems  in  the  pipeline  or  still  being 
maintained  by  the  developing  command.  Of  the  remainder,  about  half 
have  contractor  involvement,  as  shown  in  Exhibit  VI- 1 . 

• The  services  see  and  are  planning  for  an  increase  in  contractor  maintenance. 
Not  only  that,  but  they  also  see  (and  are  encouraging)  much  more  ECS 
software  maintenance  being  performed  by  firms  who  are  not  the  original 
developers  (third-party  maintenance). 

All  three  services  cited  this  as  both  a trend  and  a goal. 

. The  dislike  of  sole  source  contracts  (in  both  procurement  and 
management)  is  increasing. 

. The  services  also  see  competitive  procurements  as  a means  of 
improving  the  quality  of  both  software  and  documentation. 

• As  the  services  begin  to  understand  their  needs  in  ECS  software  maintenance 
better,  they  are  getting  away  from  buying  on  a price  basis. 

They  understand  that  there  will  be  too  many  factors  (some  of  which  are 
unforeseeable)  that  are  dependent  on  a firm  being  actually  able  to 
perform  a task,  rather  than,  say,  just  supplying  bodies  at  a rate  per 
body. 

• The  Air  Force,  for  example,  sees  there  being  a cycle,  or  pendulum,  in  regard 
to  the  importance  of  price: 
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VI  ECS  SOFTWARE  MAINTENANCE  BUSINESS  ISSUES 


• In  considering  entry  into  the  ECS  software  maintenance  business,  several 
issues  must  be  considered: 

What  is  the  real  and  perceived  need  for  software  maintenance  con- 
tractors from  the  services'  viewpoint? 

How  do  contractors  perceive  software  maintenance? 

What  is  the  competitive  environment? 

What  are  the  choices  in  organizing  an  ECS  software  maintenance 
undertaking? 

A.  THE  NEED  FOR  SOFTWARE  MAINTENANCE  CONTRACTORS 


I.  AMOUNT  OF  CONTRACTOR  USE 

• Currently,  about  half  of  software  maintenance  is  being  carried  out  by 
contractors. 

The  Navy  is  using  about  60%  contractors. 
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. Air  Force  Logistics  Command  has  spent  about  $80  million  on  con- 
tractors and  $90  million  on  organic  (in-house)  ECS  software  main- 
tenance in  1 980. 

. The  contractor  portion  is  growing  over  25%  annually. 

The  Army  still  has  many  of  its  ECS  systems  in  the  pipeline  or  still  being 
maintained  by  the  developing  command.  Of  the  remainder,  about  half 
have  contractor  involvement,  as  shown  in  Exhibit  VI- 1 . 

• The  services  see  and  are  planning  for  an  increase  in  contractor  maintenance. 
Not  only  that,  but  they  also  see  (and  are  encouraging)  much  more  ECS 
software  maintenance  being  performed  by  firms  who  are  not  the  original 
developers  (third-party  maintenance). 

All  three  services  cited  this  as  both  a trend  and  a goal. 

. The  dislike  of  sole  source  contracts  (in  both  procurement  and 
management)  is  increasing. 

. The  services  also  see  competitive  procurements  as  a means  of 
improving  the  quality  of  both  software  and  documentation. 

• As  the  services  begin  to  understand  their  needs  in  ECS  software  maintenance 
better,  they  are  getting  away  from  buying  on  a price  basis. 

They  understand  that  there  will  be  too  many  factors  (some  of  which  are 
unforeseeable)  that  are  dependent  on  a firm  being  actually  able  to 
perform  a task,  rather  than,  say,  just  supplying  bodies  at  a rate  per 
body. 

• The  Air  Force,  for  example,  sees  there  being  a cycle,  or  pendulum,  in  regard 
to  the  importance  of  price: 
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EXHIBIT  VI-1 


ARMY  CONTRACTOR  USAGE 


USAGE 

NUMBER  OF 
SYSTEMS 

Contractor  Only 

13 

Combat  Developer  (User) 

5 

Developing  Command 

18 

Readiness  Command 

3 

Depot 

4 

Mixed  - Contractor/Government 

15 

Total 

58 
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„ "High  price  has  been  OK"  for  good  work. 


"Reputation  is  becoming  more  important  than  price." 

• The  Army  took  great  pains  to  point  out  that  even  its  present  ECS  software 
maintenance  procurement  procedures  were  not  price  bound  ("although  some 
vendors  don't  understand  this"). 

Vendors  are  divided  into  three  groups  (superior,  acceptable,  and  unac- 
ceptable). The  Army  decides  which  of  the  top  two  categories  is  needed 
for  a particular  software  maintenance  job  and  then  chooses  on  price. 

The  process  is  expected  to  give  even  more  weight  to  performance 
criteria  in  the  future. 

2.  ATTITUDES  TOWARD  CONTRACTOR  USAGE 

• This  is  largely  a headquarters/field  split  in  attitudes. 

• The  headquarters  is  results  oriented,  aware  of  internal  staff's  shortcomings, 
and  used  to  dealing  with  contractors. 

• The  field  units'  attitudes  are  mixed. 

There  are  positive  attitudes  based  on  favorable  experiences  working 
with  contractors.  They  will  also  admit  their  own  resource  limitations. 

On  the  other  hand,  field  staff  are  often  defensive  and/or  overconfident 
concerning  their  own  and  their  staffs'  qualifications.  Empire  building  is 
also  a factor. 

These  attitudes  can  reside  within  the  same  person. 
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There  is  also  an  attitude,  prevalent  enough  to  be  a conference  presentation,  as 
shown  in  Exhibit  VI-2,  that  contractors,  especially  sole  source  procurements, 
are  much  more  expensive. 

It  is  widely  recognized  that  there  are  many  pressures  favoring  the  increased 
use  of  contractors.  These  include: 

Limitations  on  government-employed  personnel,  both  body  counts  and 
budget  ceilings. 

Lack  of  in-house  skills  and  training. 

Software  engineer  disincentives. 

. Noncompetitive  salary. 

. Promotion  barriers  for  those  still  using  their  technical  skills. 

An  attrition  rate  among  computer-experienced  officers  of  at  least  50%; 
Exhibit  VI-3  illustrates  ECS  staffing  pressures. 

These  factors,  taken  together,  indicate  that  there  should  be  little,  if  any,  real 
growth  in  government  capacity  to  perform  ECS  software  maintenance. 

OTHER  FACTORS 

There  is  a school  of  thought  that  believes  that  the  original  developer  and/or 
current  software  maintainer  has  such  a strong  edge  that  new  companies  cannot 
compete.  There  is,  of  course,  some  truth  to  this.  However,  government 
respondents  took  care  to  point  out  factors  that  counterbalanced  these: 

Some  developers  have  a low  interest  in  and/or  aptitude  for  main- 
tenance. 
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EXHIBIT  VI-2 


ECS  SUPPORT  COSTS:  SERVICE  VIEWS  OF  ALTERNATIVES 


SOURCE: 


CORDER,  NAECON  1980 


EXHIBIT  VI-3 


ECS  OFFICER  SHORTAGE 


"WANTED : 

Captains /Majors  with  experience  in  acquisition  of 
computer  resources  in  weapon  systems  wanted  to 
work  in  the  directorate  of  computer  resources  devel- 
opment policy  and  planning  (XRF),  DCS/Plans  and 
Programs,  HQ  AFSC.  For  further  information,  contact 
Col.  John  J.  Marciniak,  AV  858-5731." 

AF  Logistics  Command  Embedded  Computer 
Resource  Newsletter. 
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„ After  working  with  a contractor  for  a period  of  time,  one  can  see  both 
strengths  and  weaknesses.  The  weaknesses  are  often  emphasized  (the 
"grass  is  greener"  syndrome). 

The  contractors  themselves  have  a tendency  to  overbid  since  they  know 
everything  that  might  possibly  go  wrong  and  overcompensate  for  this. 

. Note:  Respondents  felt  that  system  knowledge  and  documen- 

tation issues  were  usually  neutral  ones.  A truly  undocumented 
(or  underdocumented)  system  is  a problem  to  both  current  and 
potential  maintainers. 

® If  the  services  would  centralize  their  ECS  software  maintenance,  this  would 
impact  the  need  for  and  use  of  contractors  in  several  different  ways. 

In  spite  of  the  Air  Force  Long  Range  Plan  stating  that  "centralization 
of  highly  skilled  engineers  is  approaching  compulsory,"  it  is  not  at  all 
clear  that  it  will  take  place  because  of  bureaucratic  opposition  and  the 
one-time  expense  and  disruption. 

As  discussed  in  the  previous  chapter,  this  would  assist  the  services  by 
utilizing  resources  better,  reducing  duplication,  and  improving  inter- 
operability. 

• There  would  also  be  advantages  to  contractors  (which  are  not  mentioned  in  the 
Air  Force  plan). 

Contractors  would  have  greater  knowledge  and  flexibility. 

It  would  be  easier  to  construct  a contractor  maintenance  career  path. 

Contractors  would  be  more  likely  to  hold  highly  skilled  people  within 
the  company.  Employees  now  often  stay  with  the  service  or  new 
contractor  if  the  contractor  changes. 
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A centralized  operation  would  make  it  feasible  to  have  personnel 
rotate  between  related  tasks  in  the  same  area. 


B.  THE  MARKET  FROM  THE  CONTRACTOR'S  VIEWPOINT 


I . MARKET  SEGMENTATION 

• Overall  ECS  market  shares  by  platform  and  service  are  shown  in  Exhibit  VI-4. 

The  Army/land  share  should  go  up  several  percentage  points  in  the 
future  because  of  the  large  number  of  new  Army  ECS  systems  in  the 
pipeline. 

These  figures  are  for  total  ECS  spending.  Software  maintenance  shares 
should  be  in  proportion  to  overall  spending. 

• Exhibit  VI-5  breaks  out  product/market  segments  by  service  and  functional 
area. 


This  exhibit  emphasizes  the  wide  range  of  service  commonalities,  a fact 
sometimes  lost  sight  of  when  dealing  with  a particular  weapons  system 
or  unique  CPU/language. 

• Exhibit  VI-6  assesses  the  individual  service  environments  from  a contractor 
perspective. 

This  exhibit  should  not  be  used  to  decide  whether  or  not  to  do  business 
with  a particular  service. 

. Depending  on  the  circumstances  and  strategy  employed,  either  a 
high  or  low  for  any  of  the  criteria  can  be  favorable. 
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EXHIBIT  VI-4 


ECS  SHARES  BY  PLATFORM  AND  SERVICE 


ECS  SHARES 

CURRENT 

PERCENT 

FUTURE 

TREND 

e Platform 

- Air 

46% 

Stable 

- Land 

27 

Up 

- Sea 

27 

Down 

• Service 

- Navy 

44 

Down 

- Air  Force 

30 

Down 

- Army 

26 

Up 

Source:  EIA  Study  and  INPUT 
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EXHIBIT  VI-5 


ECS  PRODUCT /MARKET  SEGMENTS 


FUNCTIONAL  DIVISION 
(INCLUDES  ASSOCIATED  ATE, 
SIMULATORS,  ETC.) 

SERVICE 

ARMY 

NAVY 

AIR 

FORCE 

OTHER 

Avionics  Systems 

M 

H 

H 

- 

Missiles  and  Ordnance: 

• Strategic 

- 

H 

H 

- 

• Tactical 

H 

H 

H 

- 

Communications,  Command,  and 
Control  Systems 

M 

H 

H 

H 

Data  Acquisition,  Non-Avionics 
(EW,  Intelligence,  Sensor 
Systems) 

M 

M/H 

H 

H 

Key : 

H = High  Intensity 
M = Medium  Intensity 
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EXHIBIT  VI-6 


SERVICE  ECS  MARKET  ENVIRONMENTS 


CRITERIA 

ARMY 

NAVY 

AIR  FORCE 

• 

System  Technical  Sophistication 

Current 

M 

M/H 

H 

- Future 

M/H 

H 

H 

Needed 

H 

H 

H 

• 

Amount  of  Software  Deployed 

L 

M/H 

H 

• 

Size  of  Software  Pipeline 

H 

M 

M 

• 

Personnel  Quality 

L/M 

M 

H 

• 

Software  Support  Planning 

M 

L 

H 

• 

Software  Support  Organization 

Near  T erm 

L/M 

L 

M 

Longer  Term 

L 

? 

H? 

• 

Software  Support  Contractor 
Relationships 

Amount  of  Experience 

L 

M 

H 

- Attitude 

L/M 

M 

H 

• 

Central  Direction 

L 

M 

H 

Key:  H = High  M = Medium  L = Low 
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„ . For  example,  the  low  amount  of  central  direction  in  the  Army 
would  mean  that  successful  vendors  would  work  with  user/R&D 
commands;  while  working  successfully  with  the  Air  Force  would 
mean  working  with  Logistics  Command. 

MARKET  SHARE 

Given  the  present  50%  use  of  contractors  and  the  total  ECS  software  spending 
shown  in  Exhibit  V- 20,  this  produces  a 1981  estimated  market  size  of  $900 
million. 

Since  this  figure  is  built  up  out  of  several  other  estimates,  it  is  subject 
to  variation,  perhaps  as  much  as  20%. 

However,  the  order  of  magnitude  is  correct  given  the  data  on  Air  Force 
Logistics  Command  spending. 

The  proportion  of  1990  spending  going  to  contractors  will  have  to  rise  to  the 
80%  to  90%  contractor  level,  if  the  government's  real  (i.e.,  personnel) 
resources  remain  constant. 

This  would  bring  the  1990  market  for  ECS  software  contractors  to 
about  $ 16  billion  (in  1990  dollars;  in  1981  dollars  this  would  be  about  $8 
billion). 

The  U.S.  military  market  is  not  the  only  market  available.  Exhibit  VI-7  shows 
the  extent  of  foreign  aircraft  sales.  As  sophisticated  systems  are  sold  to 
foreign  governments,  there  is  an  almost  inevitable  need  for  support. 

The  foreign  buyers  often  believe  that  they  can  provide  the  ECS  support 
themselves,  but  find  that  they  cannot. 

The  U.S.  military  usually  looks  to  private  contractors  to  provide  the 
necessary  support. 
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EXHIBIT  VI-7 


FOREIGN  AIRCRAFT  SALES 


COUNTRY 

E3A 

F4 

F5 

F 1 5 

FI  6 

Fill 

FI  8 

Australia 

X 

+ 

Belgium 

X 

Bolivia 

X 

Brazil 

+ 

Canada 

+ 

X 

Chile 

+ 

Denmark 

X 

X 

Egypt 

+ 

Ethiopia 

+ 

Germany 

+ 

Greece 

+ 

+ 

X 

Indonesia 

+ 

Israel 

+ 

y 

+ 

X 

Japan 

+ 

X 

Jordon 

+ 

+ = Actual 
X = Projected 


Continued 


EXHIBIT  VI-7  (Cont.) 
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FOREIGN  AIRCRAFT  SALES 


COUNTRY 

E3A 

F4 

F5 

FI  5 

FI  6 

Fill 

FI  8 

Korea 

+ 

+ 

X 

Libya 

+ 

Malaysia 

+ 

Morocco 

+ 

Netherlands 

X 

+ 

X 

Norway 

X 

+ 

X 

Philippines 

+ 

Saudi  Arabia 

O- 

X 

Singapore 

+ 

Spain 

+ 

+ 

X 

Sudan 

+ 

Switzerland 

+ 

Taiwan 

United  Kingdom 
Venezuela 

+ 

+ 

X 

+ = Actual 
X = Projected 
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PERCEIVED  MARKET  IMPORTANCE 

Vj 


• The  services  have  a much  clearer  view  of  the  importance  and  growth  of  third- 
party  ECS  software  maintenance  than  do  many  potential  contractors.  Vendors 
have  different  views  on  this  subject. 

Some  choose  to  ignore  the  issue  or  just  view  maintenance  requirements 
as  something  that  slows  down  development  or  makes  it  more  difficult. 

Others  see  it  as  either  an  automatic  development  follow-on  or  an 
equally  automatic  transfer  to  the  services  for  maintenance. 

. As  discussed  earlier,  both  of  these  views  are  faulty. 

Another  extremely  interesting  category  is  companies  that  actively 
avoid  taking  on  ECS  software  maintenance  responsibilities.  Both  GE 
and  McDonnell-Douglas  were  described  by  government  respondents  as 
having  refused  to  be  considered  for  maintaining  systems  that  they 
themselves  had  developed. 

. The  cited,  extremely  plausible,  rationale  was  that  software 
maintenance  is  a low-status,  low-skill  occupation  that  their 
employees  did  not  wish  to  become  involved  with. 

. This  is  a current  fact  of  life  and  will  be  discussed  in  the  next 
subsection. 

It  is  fair  to  say  that  many,  if  not  most,  vendors,  even  those  currently 
performing  ECS  software  maintenance,  are  unaware  of  the  magnitude 
of  the  opportunity.  There  are  several  reasons  for  this: 

. The  services  themselves  are  only  now  sorting  out  the  issues 
involved  and  planning  for  the  long  term. 
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, . There  is  now  plenty  of  ECS  software  development  work  so 

contractors  do  not  have  to  focus  on  the  maintenance  area* 

. Data  on  which  to  make  decisions  varies  between  being  incom- 
plete and  non-existent. 

. Software  maintenance  is  seen  as  a low  form  of  activity  with 
which  a self-respecting  state-of-the-art  firm  or  person  does  not 
become  involved. 

THE  SOFTWARE  MAINTENANCE  IMAGE 

It  is  almost  impossible  to  overstate  the  horrible  image  attached  to  software 

maintenance. 

"Garbage  picker"  might  be  appropriate. 

There  is  a strong  view,  held  by  both  developers  and  maintainers  that 

there  is  no  advancement  possible  and  that  only  inferior  people  get 

involved  with  maintenance. 

. A software  maintainer  does  simple-minded  work  and  does  not 
improve  professionally. 

The  reality  usually  is  bad. 

Maintenance  personnel  often  work  with  obsolescent  software. 

The  reward  for  success  is  being  stuck  in  a particular  application 

indefinitely. 

There  is  no  obvious  career  path  (except  out  of  maintenance). 
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There  is  no  body  of  knowledge  or  tools  to  make  the  work  easier  or  more 
professionally  fulfilling. 

• As  stated  earlier,  the  objective  requirements  of  software  maintenance  are  at 
least  as  demanding  as  in  development.  Obviously,  this  is  not  always  perceived 
by  either  those  assigning  the  work  or  those  performing  the  work. 

The  result  is  unsatisfactory  performance  in  terms  of  one  or  more  of  the 
following: 

. Quality  of  deliverables. 

. Cost. 

. Time  required. 

• Some  organizations  are  more  successful  than  others  in  improving  both  the 
image  and  product  of  software  maintenance  (the  two  are  closely  related): 

Some  will  call  it  something  else  or  avoid  calling  it  anything  ("X"  System 
Group,  rather  than  "X"  System  Maintenance  Group). 

. This  can  be  surprisingly  effective,  but  is  often  difficult  to  do  in 

large  organizations  which  prefer  clarity  rather  than  obscurity  in 
titles. 

Others  purposely  mix  development  and  maintenance  within  the  same 
group.  This  works  even  where  maintenance  is  a very  high  proportion  of 
work  done. 

. This  example  is  not  useful,  however,  when  seeking  to  enter  the 
software  maintenance  business. 
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The  most  interesting  case  is  the  systems  programming  staff  which  in 

reality  performs  almost  pure  maintenance.  Yet  this  function  is  very 

high  status.  This  has  occurred  for  a mixture  of  reasons: 

. Systems  programmers  deal  with  the  heart  of  the  computing 

system.  The  mystique  rubs  off. 

. In  the  past,  the  job  was,  in  fact,  much  more  creative  than  it  now 

is.  It  used  to  be  common  to  make  operating  system  changes  for 
a particular  installation. 

. Systems  programmers  are  viewed  as  a repository  of  technical 
knowledge  (and  often  are).  This  confers  status. 

. The  case  of  the  systems  programmers  is  not  directly  applicable 
to  ECS  software  maintenance.  However,  there  are  lessons  that 
should  be  applied.  (These  will  be  discussed  in  Section  D of  this 
chapter.) 

In  general,  though,  the  exceptions  merely  prove  the  rule  that  software 
maintenance  is  looked  down  on  and  is  often  ineffective. 

There  is  high  turnover. 

Much  of  the  work  is  costly  and  ineffective. 

There  is  little  sense  of  direction  or  view  of  software  maintenance  as  an 

organized  discipline. 
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COMPETITION 


I.  STATUS 

• As  discussed  in  the  prior  section,  competitors  and  potential  competitors  are 
only  slowly  focussing  on  the  fact  that  there  is  a market  for  third-party 
software  maintenance. 


Only  two  of  the  thirteen  experts  interviewed,  for  example,  saw  third- 
party  ECS  software  maintenance  as  an  important  factor. 

. They  were,  however,  two  of  the  more  astute  respondents  and 
were  associated  with  leading  edge  companies. 

• The  image  of  the  competition  varies.  Because  of  the  sensitivity  of  many 
government  personnel  in  evaluating  companies  and  because  F ACC’s  sponsor- 
ship of  this  study  was  often  disclosed  in  order  to  obtain  interviews  (with  FACC 
knowledge  and  approval),  respondents  were  not  asked  to  evaluate  specific 
competitors.  However,  a number  of  respondents  volunteered  views  on 
individual  companies  (as  well  as  generic  statements  cited  earlier  in  this 
chapter).  Comments  on  specific  firms  include: 

TRW. 


. "High  confidence  factor." 

. "Excellent  maintainability,  even  though  not  intentional." 
Boeing  Aircraft:  not  good. 

. But  Boeing  technology:  very  good. 

GE:  depends  on  division. 
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An  unexpected  finding  in  the  interview  process  was  the  unsolicited  comments 
volunteered  concerning  FACC,  as  shown  in  Exhibit  VI-8. 

The  attitudes  expressed  here  could  result  in  problems  for  an  ECS 
software  maintenance  undertaking,  at  least  until  it  is  able  to  build  up 
an  independent  image  of  its  own. 

Too  much  should  not  be  made  of  these  comments.  As  one  respondent 
said  (concerning  another  vendor):  "People  always  come  in  with  a better 
reputation  than  they  go  out  with." 

COMPETITORS 

A rare  opportunity  to  evaluate  contractor  interest  and  involvement  with  ECS 
software  maintenance  was  at  the  Second  Joint  Logistics  Commanders 
Software  Workshop  (1981). 

Both  the  services  and  contractors  took  part.  Exhibit  VI-9  analyzes  both 
service  and  vendor  participation. 

. Note  that  while  the  services  supplied  44%  of  the  participants, 
they  chaired  only  21%  of  the  panels. 

Exhibit  VI- 10  shows  the  much  greater  attendance  by  the  Air  Force  and 
Navy  than  the  Army. 

. Note  that  the  Air  Force  chaired  three  out  of  the  four  panels 
chaired  by  service  personnel. 

An  index  of  vendor  activity  can  be  seen  by  the  number  of  participants 
attending  and  the  number  of  panels  chaired,  as  shown  in  Exhibit  VI- 1 I. 

There  tends  to  be  a high  correlation  in  the  leaders  of  both  lists. 
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EXHIBIT  VI-8 


UNSOLICITED  COMMENTS  ON  FACC 


• "Does  FACC  want  to  produce  good  documentation?  I suspect  it 
doesn't  want  to." 


s "Impressed  with  FACC  build-up  in  software  capability.  Not 
impressed  with  FACC  being  unaware  of  needs.  Several  times 
FACC  approached  to  bid  on  a system  months  too  late." 

• FACC  "has  special  problem  being  identified  with  Chrysler  (situation). 

Must  be  perceived  as  independent."  (Note:  Occurred  during 
week  Chrysler  tank  division  sold  to  General  Dynamics.) 

• A recent  FACC  product:  "Lousy;  dumb  design.  A hundred 

problems  a month  for  six  months." 

• "FACC  people  were  good  on  maintaining  hardware.  But  front- 
loaded  contract,  started  to  lose  money  and  cut  and  ran." 


EXHIBIT  VI-9 
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JOINT  LOGISTICS  COMMANDERS  (JLC) 
1981  SOFTWARE  WORKSHOP: 
PARTICIPATION  ANALYSIS 


SERVICES:  57  Participants 

VENDORS:  43  Companies,  73  Participants 


COMPANY 

PARTICIPATION 

NUMBER  OF  PARTICIPANTS 

1 

2 

3 or  4 

5 or  6 

Number  of  Companies 

30 

4 

5 

4 
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EXHIBIT  VI-10 


JLC  1981  SOFTWARE  WORKSHOP: 
SERVICE  PARTICIPATION 


PARTICIPANTS 

TOTAL 

• 

Army  (Darcom)  (*) 

11 

• 

Navy 

20 

- Material  Command 

(18) 

- Others 

( 2) 

• 

Air  Force 

20 

- Systems  Command  (*)  (*) 

( 6) 

- Logistics  Command  (*) 

(12) 

- Other 

( 2) 

• 

Other  DOD 

6 

Total 

57 

(*)  Chaired  Panel 
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EXHIBIT  VI-11 


JLC  1981  SOFTWARE  WORKSHOP: 
LEADING  VENDOR  PARTICIPANTS 


PARTICIPANT  NUMBERS 

PANELS  CHAIRED 

Sperry-Univac 

6 

Computer  Sciences  Corporation 

3 

General  Electric  Company 

5 

TRW 

2 

Hughes  Aircraft  Company 

Aerospace  Corporation 

1 

TRW 

5 

Dynamics  Research  Corporation 

1 

Teledyne/Brown  Engineering 

4 

Hughes  Aircraft  Company 

1 

Aerospace  Corporation 

3 

ITT 

1 

Computer  Sciences  Corporation 

3 

Raytheon  Company 

1 

ITT 

3 

ROLM 

1 

Raytheon  Company 

3 

Singer-Kearfoot 

1 

Teledyne/Brown  Engineering 

1 

System  Development 
Corporation 

1 

Higher  Order  Software 

1 
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Sperry  and  GE  are  obviously  trying  to  find  out  what  is  going  on,  but  do 
not  yet  have  any  standing  in  the  ECS  software  community. 

• Exhibit  VI- 1 2 lists  all  vendors  attending  the  conference,  noting  how  many 
people  participated  and  whether  the  company  chaired  panels. 

Many  of  the  leading  firms  in  the  defense  and  computer  communities 
attended. 


D.  ECS  SOFTWARE  MAINTENANCE  OPTIONS 


I . KNOWLEDGE  REQUIRED  FOR  ECS  SOFTWARE  MAINTENANCE 

• There  are  three  different  levels  of  knowledge  required  to  perform  satisfactory 
ECS  software  maintenance: 

Technical  knowledge. 

Functional  knowledge. 

Mission  knowledge. 

• Currently,  there  is  considerable  confusion  between  these  three  levels.  There 
is  a tendency  to  focus  on  technical  knowledge  and  issues,  in  large  part  because 
of  the  obvious,  critical  problems  to  be  resolved. 

However,  there  is  also  an  element  of  comfort  involved  in  dealing  with 
familiar  technical  issues. 

Exhibit  VI- 1 3 shows  what  is,  in  INPUT'S  view,  the  proper  relationship 
between  the  three  levels  of  knowledge. 


-122- 


ir 


EXHIBIT  VI-12 


JLC  1981  SOFTWARE  WORKSHOP:  VENDOR  PARTICIPATION 


Aerospace  Corporation  (3)  (*) 

Martin-Marietta  Aerospace  (1) 

Analytical  Systems  Engineering  (1) 

Medtronics,  Inc.  (1) 

Anchor  Software  (1) 

Mitre  Corporation  (1) 

Boeing  Aerospace  (1) 

MRJ , Inc.  (1) 

CTEC,  Inc.  (1) 

Norden  Systems  (1) 

CSC  (3)  (*)  (*)  (*) 

Raytheon  Company  (3)  (*) 

Dynamics  Research  Company  (2)  (*) 

RCS  (1) 

Emerson  Electric  (1) 

ROLM  (1)  (*) 

Fairchild  (1) 

SAI  (1) 

Garrett  Manufacturing  Co.  Inc.  (1) 

Sanders  Associates,  Inc.  (1) 

General  Dynamics  Corporation  (1) 

SDC  (2)  (*) 

General  Electric  Company  (5) 

Singer-Kearfoot  (1)  (*) 

GTE  /Sylvania  (1) 

Softech,  Inc.  (1) 

Higher  Order  Software  (1)  (*) 

Sperry-Univac  (6) 

Hughes  Aircraft  Company  (5)  (*) 

Strategic  Systems  (1) 

IBM  (2) 

Teledyne/B rown  Engineering  (4)  (*) 

ITT  (3)  (*) 

Texas  Instruments,  Inc.  (1) 

Intercom  Systems  (1) 

Tracor,  Inc.  (1) 

Litton  Industries  (1) 

TRW  (5)  (*)  (*) 

Lockheed  (1) 

Vought  Corporation  (1) 

Logicon,  Inc.  (1) 

Magnavox  Display  Systems  (2) 

Westinghouse  Aero  (1) 

(*)  Chaired  Panel 
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EXHIBIT  VI-13 


KNOWLEDGE  LEVELS 


IN 
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Technical  knowledge  focuses  on  software  methodology;  i.e.: 


Software  system  design/modification. 

Software  module  design/modification. 

Coding  and  languages. 

Software  problem  identification/resolution. 

. Pre-operation  = debugging,  testing,  and  verification. 

. Post-operation  = maintenance. 

This  knowledge  resides  in  computer  programmers  and  technical  assis- 
tants. 

. The  skill  levels  required  may  range  from  low  to  high. 

Functional  knowledge  is  non-mission  related,  but  cuts  across  both  software 
systems  and  weapons  systems. 

Examples  include: 

. Data  base  management. 

. Embedded  computer  system  networks. 

. Interoperability  concepts. 

This  knowledge  resides  in  computer  scientists  or  software  engineers. 

. Required  skills  range  from  medium  to  very  high. 


-125- 


INPUT 


• Mission  knowledge  builds  on  technical  and  functional  knowledge  and  also 
incorporates  hardware  knowledge.  It  often  cuts  across  services/programs.  It 
may  also  cut  across  or  incorporate  knowledge  of  several  (or  many)  embedded 
computer  systems. 

Examples  include: 

. Avionics  subsystems. 

. Communications. 

. Command  and  control. 

. Sensors. 

This  knowledge  resides  in  multiskilled  systems  (e.g.,  electrical  engi- 
neers and  computer  scientists). 

. The  required  skills  are  usually  high. 

• Exhibit  VI- 1 4 summarizes  the  characteristics  and  background  of  the  types  of 
personnel  involved  m the  three  levels. 

Those  people  needed  to  carry  out  the  functional  and,  especially,  the 
mission  tasks  require  considerable  experience  that  is  often  only  obtain- 
able on  the  job. 

2.  CURRENT  ECS  SOFTWARE  MAINTENANCE  PROBLEMS 

• The  division  of  responsibility  is  now  often  unclear  between  engineers,  com- 
puter scientists,  and  computer  technicians. 

• The  process  is  very  labor  intensive. 
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EXHIBIT  VI-14 


ECS  SOFTWARE  PERSONNEL  CHARACTERISTICS 


CHARACTERISTICS 

PERSONNEL  TYPE 

SYSTEM 

ENGINEER 

COMPUTER 

SCIENTIST 

PROGRAMMER 

TECHNICIAN 

Experience  Required 
(Years,  Minimum) 

6-10 

2-3 

1 . 5- 1 . 0 

0.  25 

Classroom-T  ype 
Training  Sufficient? 

Rarely 

Often 

Usually 

Yes 

Hardware  Knowledge 
Required  ? 

Yes 

Sometimes 

Rarely 

No 

1 nterchangeability 

Low 

Medium 

High 

Very  High 

INPUT 
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Methodological  approaches  are  uncertain. 


Much,  usually  too  much,  of  the  process  is  an  art  not  a science. 

Scarce  and  expensive  engineering  skills  are  often  diverted  to  coding  and 

clerical  functions. 

• Relatively  few  tools  exist.  What  does  exist  is  of  variable  quality/utility.  In 
any  case  tools  are  not  standardized. 

• The  result  is  a high-cost,  often  indifferent  product. 

Personnel  waste  is  the  most  critical  issue. 

• One  way  of  addressing  software  maintenance  problems  is  to  match  require- 
ments to  personnel  levels,  as  shown  in  Exhibit  VI- 1 5. 

© Another  approach  is  to  organize  the  software  maintenance  function  in  the 
most  suitable  manner. 

3.  APPROACHES  TO  THE  MAINTENANCE  FUNCTION 

• There  are  three  general  ways  of  supplying  the  maintenance  function: 

"Body” shop. 

Systems  support. 

Software  improvement, 
a.  Body  Shop 

• The  body  shop  approach  inserts  personnel  into  the  client  organization.  Usually 
the  client  directs  and  manages  the  personnel. 
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EXHIBIT  VI-15 


FUTURE  MATCHING  OF  REQUIREMENTS  AND  PERSONNEL 


INPUT 

YFA2  P 


This  approach  is  popular  for  avoiding  personnel  ceilings/uncompetitive  salaries 
or  acquiring  scarce  skills. 

The  benefits  are  marginal  to  the  supplier.  The  leverage  is  small.  There  is  a 
cloudy  external  image.  Internal  knowledge  building  is  variable,  usually  low. 

There  is  low  value  added,  consequently  profit  margins  are  low. 

Typically,  there  is  marginal  loyalty  by  employers. 

An  example  is  Lincoln  Labs  for  FACC. 

b.  Systems  Support 

The  systems  support  approach  is  similar  to  a facilities  management  contract. 
It  can  be  either  short  or  long  term. 

It  is  usually  "process,"  as  opposed  to  "task"  oriented.  That  is,  a system 
will  be  maintained  over  a period  of  time. 

Problems  arise  since  it  is  very  difficult  to  forecast  in  advance  the 
precise  requirements  that  will  have  to  be  met. 

. The  pressures  are,  therefore,  strong  for  this  type  of  arrangement 
to  recede  into  a level  of  effort,  or  body  shop  approach. 

c.  Software  Improvement 

The  key  to  the  software  improvement  approach  is  that  it  is  not  project 
oriented. 

Both  the  body  shop  and  systems  support  approaches  are  task  oriented. 
Organizations  are  ad  hoc  and  temporary.  Skill  groupings  are  put 
together,  only  to  be  taken  apart  after  a relatively  short  time. 


It  is  not  surprising  that  turnover  is  high  and  loyalty  is  often  low. 


The  software  improvement  approach  is,  quite  simply,  that  there  will 
always  be  software  to  improve. 

. Because  of  the  critical  mission  knowledge  required  in  ECS 
software  maintenance,  it  makes  sense  to  specialize  in  a rela- 
tively small  number  of  application  areas. 

. Even  the  scanty  tools  and  techniques  which  now  exist  could  be 
highly  leveraged  where  used  by  a continuing  organization. 

Exhibit  VI- 1 6 shows  that  the  software  improvement  approach  is  definitely 
superior  to  the  others. 

This  approach  might  be  termed  the  "professional  software  maintenance" 
approach. 

The  professional  software  maintenance  approach  would  provide  a career  path 
for  people  to  stay  within  software  maintenance. 

As  such  it  should  be  separately  organized  and  have  little  or  no 
connection  with  software  development. 

A technical  body  of  knowledge  would  soon  also  arise. 
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EXHIBIT  VI-16 


SOFTWARE  MAINTENANCE  BUSINESS  ALTERNATIVES 


ALTERNATIVES 

BODY 

SHOP 

SOFTWARE 

SUPPORT 

SOFTWARE 

IMPROVEMENT 

Individual  Skills  Required 

Software 

Varies 

M 

H 

Systems 

Varies 

H 

L/M 

Importance  of  Software  Tools 

General  Tools 

M 

M 

H 

Proprietary  Tools 

L 

M 

H 

Personnel  Benefits 

Identification  with  Firm 

L 

L/M 

H 

Opportunity  for  Growth 

L 

L/M 

M/H 

Business  Factors 

People  Leverage 

L 

M 

H 

Product  Creation 

L 

L/M 

H 

Economics  of  Scale 

L/M 

L/M 

H 

Value  Pricing 

L 

L/M 

H 

Perceived  Status 

Generally 

M 

M 

H 

By  Specific  Targets 

M 

H 

M/H 

Key:  H = High  M = Medium  L - Low 


IIS 


YF 
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VII  ECS  SUMMARY  AND  RECOMMENDATIONS 


VII  ECS  SUMMARY  AND  RECOMMENDATIONS 


A.  SUMMARY 

• There  are  both  positive  and  negative  factors  as  far  as  ECS  market  entry  is 
concerned,  as  shown  in  Exhibit  VII- 1 . 

The  positive  points  come  from  market  needs. 

The  negative  points  are  issues  in  initial  entry,  or  start-up.  No  strictly 
market  issues  were  found  that  were  negative. 

B.  RECOMMENDATIONS 

• INPUT  recommends  that  FACC  strongly  consider  entering  the  ECS  software 
maintenance  business. 

• Several  key  issues  to  be  considered  in  market  entry  are: 

General  strategy. 

Organizational  placement. 

"Make  Versus  Buy." 
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EXHIBIT  VII-1 


ECS  SOFTWARE  MAINTENANCE: 

POSITIVE  AND  NEGATIVE  MARKET  ENTRY  FACTORS 


• Positive 

Large,  growing  market 
Perceived  need 

- Not  yet  widely  perceived  as  a discrete  business 
FACC  skill  base  (actual  and  perceived)  advantageous 
Could  be  synergistic  and  complementary  to  existing  business 

• Negative 

Software  maintenance:  low  image,  in  general 

- High  skills  required 

• For  key  staff,  at  minimum 

• Potential  for  conflict  with  current  FACC  activities 
Personnel 

• Shortage 

• Turnover 
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The  key  strategic  issue  is  to  understand  that  technical  expertise  is  the 
foundation  of  success,  but  does  not  in  itself  guarantee  success,  as  shown  in 
Exhibit  VI 1—2. 


The  software  expertise  must  be  based  on  software  maintenance  engi- 
neering; i.e.: 

. Proprietary  concepts  and  tools. 

. Two-way  teaching  and  learning  from  DOD. 

The  management  process  will  foster  a software  engineering  environ- 
ment while  at  the  same  time  defining  policies  to  attract  and  hold  the 
right  staff  through: 

. Personnel  policies. 

. Financial  incentives. 

. Professional  challenges. 

. Stable  environment. 

Advanced  cost  estimation  techniques  will  help  develop  software  main- 
tenance engineering  (and  vice  versa). 

In  order  to  gain  system  understanding  FACC  should  aim  at  specific 
product/buyer  segments.  This  will  help  attain  system  and  buyer 
knowledge. 

. Segments  should  be  reinforcing,  both  with  each  other  and  with 
other  FACC  activities. 
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EXHIBIT  VI 1-2 


SOFTWARE  BUSINESS  KEYS  FOR  SUCCESS 


EXPERTISE  PERCEIVED 


UNDERSTANDING  OF  CUSTOMER 


UNDERSTANDING  OF  SYSTEM 


MANAGEMENT  PROCESS 


COST  ESTIMATE/CONTROL 


TECHNICAL  EXPERTISE 
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. Being  a subcontractor  in  chosen  fields  of  expertise  will  add  to 
both  system  understanding  and  customer  understanding  by  pro- 
viding greater  exposure  in  targetted  areas. 

. Subcontracting  can  provide  other  benefits  by  providing  phased 
entry  and  smoothing  workloads.  Smoothed  workloads  are  vital 
for  holding  staff. 

Achieving  the  goal  of  having  broadly  perceived  expertise  will  come 
about  by: 

. Developing  the  lower  tiers  of  the  "success  pyramid." 

. Strategic  subcontracting. 

. Targetted  professional  activities. 

. Technical  marketing  to  middle  management. 

Organizational  placement  is  also  vital  to  success. 

INPUT  believes  that  a successful  maintenance  organization  must: 

. Do  nothing  but  maintenance. 

. Be  separate  both  physically  and  organizationally  from  the  devel- 
opment group. 

If  this  is  not  done,  the  maintenance  group  will  have  its  best  staff 
drained  to  the  development  organization  and  will  be  permanently 
second  class  citizens.  The  issues  are  shown  in  Exhibit  VI 1-3. 
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EXHIBIT  VI 1-3 


EFFECTS  OF  SOFTWARE  MAINTENANCE  ORGANIZATION  OPTIONS 


MAINTENANCE  PHYSICALLY  AND 
ORGANIZATIONALLY  DISTINCT 

Yes 

No 

z LU 

o u 

P! 

< z 

^ LU 

is 

Yes 

Low  Turnover 

High  Morale 

High  Skills 

Large  Project 
Size 

High  Turnover 

Low  Morale 

Medium  Skills 

Large  Project 
Size 

,,,  o 

uj  p 

u ^ 

Z Q 

Medium  Turnover 

< LU 
Z 1- 

Medium  Morale 

LU  < 

No 

N /A 

H-  u 

Medium  Skills 

z - 

— Q 
< LU 

Medium  Project 

^ Q 

Size 

"Make  Versus  Buy"  is  a question  of  either  growing  an  organization  around  a 
few  key  individuals  or  acquiring  a company.  Either  route  demands  careful 
attention. 

Only  a few  companies,  mostly  small,  are  candidates  (e.g.,  SofTech, 
Logicon). 

. Their  turnover  is  high. 

. Their  "capital  walks  home  every  night." 

Buying  such  a company  will,  at  best,  buy  some  work  backlog.  Everything  else 
can  be  considered  a very  high  recruitment  fee. 

Recruitment  is  a viable  option.  However,  it  requires  a clear  view  by 
FACC  of  its  strategy  so  that  it  can  choose  a compatible  kernel  of  staff 
for  the  new  undertaking. 

In  either  case,  retention  of  a few  key  people  will  be  critical  for  the 
software  maintenance  business's  early  success. 

A related  issue  is  that  current  engineering  services  division  managers  who  will 
have  to  interface  with  the  software  maintenance  group  should  gain  some 
knowledge  in  the  ECS  software  maintenance  area. 

Otherwise,  they  cannot  provide  informed  support  to  the  new  business. 
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VIII  THE  FEDERAL  ADP  ENVIRONMENT  AND  SOFTWARE 

MAINTENANCE  OPPORTUNITIES 


VIII  THE  FEDERAL  ADP  ENVIRONMENT  AND  SOFTWARE  MAINTENANCE 


OPPORTUNITIES 


• This  chapter  includes: 

An  overview. 

Current  ADP  spending. 

The  ADP  software  environment. 

ADP  software  maintenance  market  size. 
Competitive  environment. 

Business  opportunities. 


A.  OVERVIEW 


• The  research  goals  for  ADP  were  similar  to  those  on  the  ECS  side. 

• It  is  important  to  understand  the  linkages: 

Between  development  and  maintenance. 
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Between  agencies. 


With  ECS. 

• Equally  important  are  the: 

Plans  (if  any). 

Central  direction  (if  any). 

• Automatic  data  processing  (ADP)  is  generally  defined  as: 

All  civilian  agency  data  processing. 

For  military,  systems  that  consist  of  off-the-shelf  hardware  and  provide 
operational  and  administrative  support. 

Equally  important,  ADP  is  covered  by  the  famous/infamous  Brooks  Act, 
which  calls  for  competitive  award  and  is  hardware  oriented. 

B.  CURRENT  ADP  SPENDING 


• The  general  ADP  spending  process  is  shown  in  Exhibit  VI II- 1 . 

The  major  areas  of  software  spending  come  from  in-house  personnel  and 
commercial  systems  analysis  and  programming  services. 

• There  is  great  difficulty  in  arriving  at  even  an  order  of  magnitude  estimate  of 
federal  ADP  software  expenditures.  The  official  estimates  in  Exhibit  VI 1 1-2  all 
purport  to  describe  the  same  universe! 
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EXHIBIT  V 1 1 1-2 


FY 80  FEDERAL  SOFTWARE  EXPENDITURES 


ACCORDING  TO  "AUTHORITATIVE 

($  billions) 

" SOURCES 

SOURCES 

EXPENDITURES 

General  Accounting  Office 

$6.  5 

Electronics  Industry  Association 

3.  5 

General  Services  Administration 

2.2 

National  Bureau  of  Standards 

0.6 
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, INPUT  interviewed  the  authors  of  the  first  three  reports  and  examined 
in  detail  the  National  Bureau  of  Standards  Report.  All  had  their 
problems,  but  only  the  General  Services  Administration  report  followed 
a logical,  defensible  approach  that  could  be  verified. 

• Because  of  that,  INPUT  believes  that  $2.2  billion  represents  a reasonable 
baseline  for  ADP  software  expenditures. 

• Taking  the  GSA  study  and  the  EIA  study's  growth  rate,  estimates  for  1980  to 
1990  were  prepared,  as  shown  in  Exhibit  VI 1 1-3. 


C.  THE  ADP  SOFTWARE  ENVIRONMENT 


• ADP  morale  in  general  is  low  and  by  all  indications  will  become  lower.  Exhibit 
VI 1 1-4  gives  representative  quotes  from  respondents. 

A few  were  positive,  most  were  negative. 

• The  new  administration's  attitude  toward  the  civil  service  and  the  ceaseless 
budget  cuts  have  been  quite  debilitating.  Many  managers  doubt  their  long- 
term ability  to  continue  to  support  their  operations. 

• This  doubt  ties  in  closely  with  the  initiative,  started  in  the  previous  adminis- 
tration and  vigorously  supported  by  the  new  administration  to  contract  out 
work  (not  just  in  ADP)  to  the  private  sector. 

• In  contrast  to  the  ECS  area,  there  are  negative  feelings  toward  software 
contractors  at  all  levels  of  management,  as  shown  in  Exhibit  VI 1 1-5. 

Some  of  this  is  normal  empire  building. 

However,  there  is  a central  core  of  truth  to  this  attitude: 
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EXHIBIT  V 1 1 1-3 


ADP  SOFTWARE 


$ BILLION 
(‘THEN-YEAR” 
DOLLARS) 

1980 

1981 

1982 

1983 

1984 

1985 

1986 

1987 

1988 

1989 

1990 

Civilian 

1.1 

1.8 

2.0 

2.2 

2.5  . 

2.9 

3.1 

3.5 

3.9 

4.4 

4.8 

DOD 

1.1 

1.8 

2.0 

2.3 

2.5 

2.8 

3.2 

3.5 

4.0 

4.4 

4.9 

Total 

2.2 

3.6 

4.0 

4.5 

5.0 

5.7 

6.3 

7.0 

7.9 

8.8 

9.7 

SOURCE:  INPUT  estimates  based  on  GSA  & EIA  studies. 


IIS 

YF 
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EXHIBIT  V1II-4 


REPRESENTATIVE  ADP  ATTITUDES 


"No  corporation  in  right  mind  would  ever  have  let 
themselves  get  in  this  mess." 

"I  love  working  in  this  place." 

"No  future." 

"A  mess." 

"We  run  a tight  ship.  People  who  can't  take  it  leave.  Last 
month  a fellow  blew  his  brains  out." 

"A  kluge." 

"A  nightmare." 

"Absolutely  horrendous." 

"Can't  blame  people  for  leaving." 

"Morass . " 

"Software  emergency." 

Quoting  recent  contractor:  "This  is  a son-of-a-bitch. " 
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EXHIBIT  V 1 1 1-5 

) 


GOVERNMENT  ATTITUDES  ON  MAINTAINABILITY 
OF  CONTRACTOR  ADP  SOFTWARE 


COMPARED  TO 

GOVERNMENT-WRITTEN  SOFTWARE 

PERCENT 

• 

Needs  More  Maintenance 

59% 

• 

Needs  Less  Maintenance 

8 

• 

No  Difference 

33 

SOURCE:  GAO  Survey  of  409  ADP  sites. 


, • The  "beltway  bandits",  i.e.,  Washington  programming  firms,  are 
known  for  taking  advantage  of  federal  customers.  In  large  part 
this  is  because  of  the  procurement  process  which  discourages  the 
building  up  of  stable  vendor-client  relationships. 

In  spite  of  these  negative  feelings,  most  ADP  managers  are  resigned  to  an 
increase  in  contractor  usage,  becuase  of: 

Their  own  inability  to  deliver  in-house  services. 

Pressures  to  use  contractors. 

ADP  management  would  be  very  receptive  to  some  kind  of  "technology 
transfer"  where  contractors  brought  in  new  tools  and  techniques  and  taught  in- 
house  staff  how  to  use  them.  However: 

This  is  partly  wishful  thinking. 

It  would  soon  be  debased  by  the  procurement  process. 

The  very  high  value  added  would  probably  be  made  into  a political 
football  and  the  contractor  would  suffer. 

Generally,  federal  ADP  software  is  a generation  behind  the  commercial  world 
in  hardware,  software,  and  management. 

There  are  islands  of  excellence  in  smaller  agencies. 

One  effect  is  that  the  maintenance  load  is  very  high. 

GSA  made  a thorough  recent  study  and  estimated  that  60%  of  software 
costs  are  for  maintenance. 

INPUT'S  interviews  confirmed  this. 
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• All  indications  are  that  this  percentage  will  increase  in  the  future,  since 
relatively  few  new  systems  are  going  into  place.  (And  all  indications  are  that 
those  that  are  installed  will  be  done  poorly  and  need  significant  maintenance 
themselves.) 

• Generally  ADP  software  maintenance  is  a shambles. 

It  receives  little  top  management  attention,  either  centrally  or  within 
agencies. 

There  is  no  uniform  definition  of  what  maintenance  is. 

There  is  little  measurement  of  either  the  size  of  the  function  or  its 
effectiveness. 

There  are  few  tools  or  standardized  approaches. 


D.  MARKET  SIZE 


• A recent  GAO  survey  and  study  provided  data  from  which  INPUT  estimates 
that  25%  of  ADP  software  maintenance  is  provided  by  contractors. 

This  means  that  the  current  market  is  $540  million. 

• Assuming  that  by  1990  software  maintenance  overall  increases  from  60%  to 
70%  and  the  contractors'  share  from  25%  to  40%,  the  estimated  1990  market 
size  would  become  $2.7  billion. 

• This  is  certainly  an  attractively  sized  market  with  a reasonable  growth  rate. 

However,  competition  is  and  will  be  keen. 
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COMPETITIVE  ENVIRONMENT 


• Software  development  and  maintenance  figures  are  generally  not  separated  in 
reporting  either  by  the  government  or  by  contractors. 

This  is  complicated  by  the  fact  that,  according  to  a GAO  study,  a 

majority  of  "maintenance"  consists  of  enhancements  (similar  to  the  ECS 

situation). 

. It  is  often  administratively  more  convenient  to  treat  such 
spending  as  "development"  rather  than  "maintenance". 

• Contractor  maintenance  is  generally  obtained  on  a "body  shop"  basis.  Both 
major  and  minor  firms  are  involved. 

Small  firms'  lower  overheads  give  them  a cost  advantage. 

. Increasingly,  minority  group  firms  are  taking  advantage  of  their 

administrative  preference  and  low  risk. 

Major  firms  involved  include: 

. Hardware  firms  (Burroughs,  Control  Data,  IBM,  etc.)  who  often 
provide  specialized  services. 

. Timesharing  firms  (Control  Data,  GEISCO,  NCSS,  Tymshare, 

McAUTO,  etc.)  who  tie-in  software  with  timesharing  services. 

. Professional  services  firms  (American  Management  Systems, 

Computer  Task  Group,  accounting  firms,  etc.). 
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BUSINESS  OPPORTUNITIES 


• There  are  opportunities,  both  general  and  specialized. 

• The  general  opportunity  is  to  become  a large,  efficient  body  shop  that  gives 
value  for  money. 

Margins  will  generally  be  low,  though,  because  these  firms  are  essen- 
tially employment  agencies  in  a price-conscious  market. 

• Another  option  is  to  seek  out  specialized  niches.  Examples  include: 

Cooperation  with  GSA's  Office  of  Software  Development  to  develop  a 
technology  transfer.  Problems  include: 

. A slow  build-up  and  possible  money  shortages. 

. FACC  would  have  to  build  product,  not  brand,  awareness. 

. It  might  be  dependent  on  a single  agency  and/or  person. 

. The  dollar  volume  could  be  relatively  low  (but  high  margin). 

Support  of  the  personal  computer  software  that  the  Naval  Automation 
Command  is  sponsoring.  Problems  include: 

. Unique  administrative  arrangements  are  probably  needed  (and 
government  is  unskilled  at  devising  them). 

. It  is  a frontier  area  both  technically  and  functionally. 

• Sudden  growth  in  the  use  of  outside  contractors  could  in  fact  "poison  the  well." 
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There  may  be  an  initial  surge  of  contractor  use  because  of  lack  of 
government  personnel  and  low  morale/productivity. 

The  rapidly  expanding  contractors  would  accentuate  their  present 
faults. 

Government  supervision  would  be  increasingly  ineffective. 

This  would  cause  successive  disasters  and  there  would  be  a political 
counter-reaction  against  contractor  use. 


-153- 


INPUT 


. 


■ 


- 154- 


* 


IX  ADP  SOFTWARE  MAINTENANCE:  SUMMARY 

AND  RECOMMENDATIONS 


ADP  SOFTWARE  MAINTENANCE:  SUMMARY  AND  RECOMMENDATIONS 


As  with  ECS  software  maintenance,  there  are  both  positive  and  negative 
aspects  to  entering  the  business  of  maintaining  ADP  software.  Exhibit  IX- 1 
summarizes  the  issues. 

Unlike  ECS,  the  negative  ADP  issues  are  market  issues  that  address  the 
basic  question,  "Should  this  market  be  entered  at  all?" 

Especially  disquieting  is  the  potential  effect  that  a changing  political 
environment  would  have:  a new  administration  and/or  a changed 

attitude  toward  contracting  out  could  greatly  reduce  market  opportuni- 
ties. 


. This  is  especially  important  since  a large  part  of  the  apparent 
market  growth  is  not  real  growth,  but  due  to  projected  inflation, 
as  shown  iri  Exhibit  IX-2. 

. After  inflation,  the  ADP  market  is  growing  at  about  one-fifth 
the  rate  of  the  ECS  market. 

This  means  that  the  overall  pie  is  growing  relatively  slowly.  This  is 
very  important  since  the  ADP  market,  unlike  the  ECS  market,  is 
already  a defined  market  with  many  established  competitors. 
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EXHIBIT  IX-1 


ADP  ENTRY:  PRO  AND  CON 


FACTOR 

POSITIVE 

NEGATIVE 

Market  Size 

Medium 

- 

Growth 

- 

Low  /Medium 

FACC  Marketing  Contacts 

Some  in  Military 

Few  in  Civilian  Agencies 

Synergy  with  ECS 

- 

Low 

Ability  to  Use  Low 
Skilled  Personnel 

Medium  /High 

- 

Margins 

- 

Low  (Especially  in 
Body  Shops) 

Effects  of.  Politics 
On  Environment 

- 

Medium  /High 

Perceived  Need  for 
Services 

- 

Medium ; 
No  Planning 

Competitors 

- 

Established 

IN 
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EXHIBIT  IX-2 


INFLATION-ADJUSTED  SOFTWARE  MAINTENANCE 
CONTRACTOR  MARKET  GROWTH,  1981-1990 

($  billions) 


1990 

REAL 

GROWTH 

(percent) 

SYSTEMS 

1981 

THEN- 

YEAR 

CONSTANT 

DOLLARS 

ADP 

$0,540 

$2.7 

$1.3 

140% 

ECS 

0.  900 

16.4 

7.7 

755 
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The  negative  factors  are  such  that  neither  FACC  nor  any  other  contractor  can 
do  much  to  change  them.  Consequently,  INPUT  does  not  recommend  that 
FACC  make  the  ADP  software  maintenance  market  a strategic  objective. 

At  best,  this  market  is  one  for  short-term  targets  of  opportunity. 

Software  maintenance  opportunities  for  commercial  accounts  are  also  rela- 
tively unpromising.  While  examining  the  commercial  opportunities  for  soft- 
ware maintenance  was  not  part  of  the  formal  research,  INPUT  has  reached 
preliminary  conclusions  in  these  areas. 

Opportunities  are  low  for  the  typical  business.  This  is  because  they 
have  similar  biases  as  government  ADP  managers,  but  none  of  the 
pressures  impelling  government  to  use  contractors. 

. There  is  little  use  now,  except  for  independent  consultants. 

. The  use  of  packaged  software  reduces  pressures  on  maintenance. 

The  private  sector  is  much  more  prone  to  use  packages  than 
government. 

Opportunities  are  low  to  medium  for  supplying  maintenance  services  to 
software  vendors. 

. They  have  fewer  empire-building  pressures  than  business  and 
there  are  some  examples  of  outside  contractor  use. 

. However,  the  proprietary  and  control  issues  are  very  important 
to  vendors  and  this  encourages  them  to  use  in-house  staff. 

If  FACC  were  to  enter  the  ADP  software  maintenance  business  it  would  have 
to  make  a basic  choice  between  the  low  road,  or  body-shop,  approach  or  the 
high  road,  or  technology  transfer,  approach. 


They  are  almost  mirror  images  of  each  other:  low  risk/yield  versus 

high  risk/yield,  as  shown  in  Exhibit  IX-3. 

There  are  two  drawbacks  to  market  entry. 

. It  will  be  very  hard  to  combine  the  two,  or  switch  from  one  to 

the  other. 

. While  the  technology  transfer  approach  is  attractive  in  many 
ways,  there  is  no  assurance  that  the  high  margins  could  be 
sustained,  mainly  for  political  reasons. 
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EXHIBIT  IX- 3 


BODY  SHOP  VERSUS  TECHNOLOGY  TRANSFER  APPROACHES 


FACTORS 

BODY  SHOP 

TECHNOLOGY 

TRANSFER 

Risk 

Low 

High 

Margins 

Low 

High  (Potential) 

Market  Receptivity 

High 

Medium  (?) 

Established 

Products/Forms 

Yes 

No 

Technology  Level 

Low 

High 

Technology  Exists? 

Yes 

No 

(Not  Organized) 

Volume 

High 

Low  (Probably) 
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CONCLUSIONS  AND  NEXT  STEPS 


A.  CONCLUSIONS 

• Except  for  some  overlap  in  markets,  as  shown  in  Exhibit  X-l,  the  ECS  and 
ADP  software  maintenance  businesses  would  have  little  in  common,  as  shown 
in  Exhibit  X-2. 

• These  dissimilarities  were  also  apparent  in  contrasting  the  major  market 
factors  of  the  ECS  and  ADP  software  maintenance  markets,  as  shown  in 
Exhibit  X-3. 

• Because  of  these  factors,  there  is  nothing  to  be  lost  if  FACC  focusses  solely 
on  the  ECS  software  maintenance  market. 

In  fact,  to  try  to  enter  both  markets  would  probably  cause  operational 
problems,  due  to  the  dissimilarity  in  the  products.  In  addition,  FACC 
management  would  be  stretched  very  thin  in  having  to  manage  such  a 
diverse  set  of  products,  activities,  and  markets. 
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EXHIBIT  X-l 


RELATIONS  OF  THREE  MARKETS 
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EXHIBIT  X-2 


ECS  AND  ADP  SOFTWARE 
MAINTENANCE  LINKAGES 


AREA 

EXTENT  OF  LINKAGE 

Buying  Points 

Low  (Civilian,  None:  Military,  Little) 

Buying  Process 

Low/Medium:  Brooks  Act  Environment 
Perceived  to  be  Quite  Different 

Skills 

Low  /Medium:  Little  Appreciation  of 
Systems  Engineering  Approach  in 
ADP 

T echniques 

Medium:  Software  Techniques  Trans- 
ferable to  ADP:  However,  Unappreciated 

Systems  Knowledge 

Low 
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EXHIBIT  X-3 


) 


ECS  VERSUS  ADP  SOFTWARE  MAINTENANCE  MARKET 


MARKET  FACTOR 

ECS 

ADP 

1 990  Market  Size  Estimate 
("Then  Year"  $) 

$16.4  billion 

$2.7  billion 

1 981-1  990  Real  Growth 
(Excluding  Inflation) 

755% 

140% 

Independence  from 
Politics 

Medium  /High 

Low 

Leverage  Potential 

High 

Medium  / Low 

FACC  Market  Knowledge 

Medium  / Low 

Low 

Synergy  with  Current 
FACC  Business 

High  (Marketing) 

Low 

Self-Aware  Competitors 

No 

Yes 
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FACC  should  decide  on  the  strategic  direction  to  be  taken.  There  are  three 
major  issues: 

Decide  on  organizational  locus  for  software  maintenance  business. 

Target  specific  market/product  areas. 

Assess  the  modes  in  which  services  can  be  delivered. 

In  addition,  the  Engineering  Services  Division  should  obtain  specific  product/ 
market  knowledge. 

ORGANIZATIONAL  LOCUS 

INPUT  had  earlier  recommended  that  FACC  ECS  software  development  and 
maintenance  activities  be  organizationally  separate  if  maintenance  is  to  be 
successful. 

If  FACC  accepts  the  principle,  it  should  then  work  out  what,  if  any, 
effects  this  would  have  on  present  and  future  software  activities. 

TARGET  MARKETS  AND  PRODUCTS 

Current  FACC  strengths  and  weaknesses  should  be  assessed  for  particular 
markets  and  products.  This  should  include  any  analysis  of  ECS  software  issues, 
including: 

Current  FACC  personnel  quality. 

Internal  FACC  assessment  of  jobs. 
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Customer  assessment  of  jobs. 


o 


FACC  product/system  experience. 

Jobs  not  bid  or  lost:  analysis. 

The  results  of  this  profile  may  be  the  determining  factor  in  selecting  certain 
product/market  combinations. 

As  noted  earlier,  there  are  few,  if  any,  product/market  combinations 
that  could  be  excluded  now  from  consideration:  they  will  all  be 

growing. 


MODE  OF  SERVICE  DELIVERY 

FACC  can  enter  the  ECS  software  maintenance  business  by  a combination  of: 

Drawing  on  internal  capabilities. 

Through  newly  hired  individual. 

Acquiring  small  companies. 

FACC  should  survey  its  own  personnel  to: 

Learn  what  capabilities  are  in-house  which  might  be  available  for  the 
new  business. 

. This  could  be  part  of  the  "strengths  and  weaknesses"  assessment. 

Part  of  the  survey  should  also  debrief  FACC  employees  on  potential 
small  companies  that  might  be  acquired  (focussing  on  key  personnel). 


t . A special  external  study  on  such  companies  would  also  be 
required. 

After  FACC  has  defined  the  potential  business  and  the  external  skills  required, 
it  should  run  a blind  ad  as  a research  tool  to  gauge  the  availability  and  quality 
of  staff. 

ACQUISITION  OF  SPECIFIC  PRODUCT/MARKET  KNOWLEDGE 

It  is  critical  that  the  Engineering  Services  Division  should  obtain  additional 
information  on: 

The  software  process. 

Weapons  systems. 

Maintenance  plans  and  philosophies  of  individual  services. 

This  information  can  be  obtained  by: 

Studying  the  documentation  obtained  for  this  study. 

Receiving  additional  briefings  from  INPUT. 

Attending  conferences  and  seminars. 

Receiving  information  from  other  FACC  units. 


- 167  - 


INPUT 


APPENDIX 


: ECS  RESPONDENTS 


APPENDIX  A: 


ECS  RESPONDENTS 


A,  ORGANIZATIONS  INTERVIEWED  - ECS 

• DOD. 

Office  of  Undersecretary  of  Defense,  Research,  and  Engineering, 
Embedded  Computer  Resources. 

Defense  Materiel  Specifications  and  Standards  Office. 

Advanced  Research  Projects  Agency  (DARPA). 

Defense  Communication  Agency. 

• Army. 

Development  and  Readiness  Command  (DARCOM). 

Armament  R&D  Command  (ARRADCOM)  Automation  Technology. 
Communications  R&D  Command  (CORADCOM). 
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Navy.  . 


Headquarters  Naval  Materiel  Command  Tactical  Embedded  Computer 
Programs  (Software  Policy). 

SEA  Systems  Command,  Naval  Shipboard  Tactical  Embedded  Computer 
Resources. 

Electronics  Systems  Command,  Life  Cycle  Engineering  and  Platform 
Integration  Directorate,  Computer  Resources  Division. 

• Air  Force. 

Logistics  and  Engineering  Air  Staff  (Software  Maintenance  Policy). 
Logistics  Command. 

. Engineering  and  Computer  Resources  (Software  Maintenance 
Planning). 

. Acquisition  Logistics  Division  (Acquisition  Liaison). 

Systems  Command. 

. Acquisition  Policy  (Life  Cycle  Requirements). 

. Electronic  Systems  Command  (Life  Cycle  Costing). 

Strategic  Air  Command. 
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APPENDIX  B:  ADP  RESPONDENTS 


APPENDIX  B: 


ADP  RESPONDENTS 


A.  ADP  SOFTWARE  - MILITARY 


• DOD  (Directorate  for  Data  Automation). 

• Air  Force. 

Directorate  of  Computer  Resources. 

. Systems  and  Resources  Division. 

. Policy  and  Acquisition. 

. Technology  Group. 

Headquarters,  Data  Systems  Design  Center. 

• Army  (Headquarters,  Computer  Systems  Command). 

• Navy. 

Headquarters,  Naval  Data  Automation  Command. 
Navy  Finance  Center. 


- 173- 


INPUT 


AD P SOFTWARE  - OVERHEAD  AGENCIES 


B. 

• OMB  (Information  Policy). 

• GSA  (Office  of  Software  Development). 

• GAO. 

• Congressional  Staff. 

C.  ADP  SOFTWARE  - CIVILIAN  AGENCIES 

• Nuclear  Regulatory  Agency. 

• IRS  (National  Computer  Center). 

• Social  Security. 

• Weather  Bureau. 

• Department  of  Transportation. 

• Postal  Service. 

• NASA. 

• Census  Bureau. 
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D.  TYPICAL  ADP  INTERVIEWEES  (TITLES) 


• Director. 

• General  Manager. 

• Manager. 

• Planning  Director. 

• Chief  (e.g.,  Software  Management). 

• Senior  Analyst. 
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APPENDIX  C:  ECS  QUESTIONNAIRE 


CATALOG  NO.  I Y I F 1 A 12  I i j i A 


SOFTWARE  MAINTENANCE:  DOD  EMBEDDED  SOFTWARE  USERS 

INTRODUCTION 


My  name  is . I am  with  INPUT,  a computer  consulting  and  research 

firm  in  Saddle  Brook,  NJ. 

We  are  performing  a study  on  the  issues  involved  in  embedded  software,  especially 
those  dealing  with  maintenance.  We  are  not  seeking  any  classified  data.  The  purpose 
of  this  study  is  to  assist  our  clients  in  planning  to  serve  the  DOD  market  now  and 
in  the  future.  In  return  for  your  taking  part  in  our  study,  we  will  send  you  a summary 
of  the  study  for  your  information  at  no  charge. 
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in  use  or  planned  in  the  next  3 years? 


CATALOG  NO.  [YiFlAI2l  I D A 
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REASON 
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Source* 
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How  often  do  you  expect  a typical  embedded  software  system  to  require: 

Source  Of 

Minimum*  Average*  Maximum*  Information  Comment 


CATALOG  NO.  I Y I FIAI  21 
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CATALOG  NO.  IYIFIAI2I  l~T 


A 


2.  Time  period  = (per  month  year,  etc. 


) 


o Do  you  expect  this  to  be  different  in,  say,  five  years?  Why? 


(NOTE:  In  later  questions  referring  to  maintenance,  the  three  above  areas  are  included.) 


3a.  What  do  you  see  as  the  critical  issues  in  embedded  software  maintenance? 
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CATALOG  NO.  lYiFlAl?!  i 1 J A 


How  do  you  see  the  issues  being  different  in,  say,  five  years? 


How  would  you  rank  machine  dependence  of  current  languages  on  a scaie 
of  I to  5?  (5=very  dependent;  I =not  dependent) 

• What  do  you  believe  the  situation  will  be  like  in  5 years? 


Comment 


• Ten  years? 


Comment 
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CATALOG  NO. 


A 


5.  To  what  extent  do  you  see  it  necessary  that  maintenance  of  embedded  software 
and  associated  hardware  be  performed  by  the  same  organization?  (Discuss) 


How  will  this  situation  change  in  the  future? 


6.  What  effect  do  you  believe  that  ADA,  its  support  enviornment  and  follow- 
on  languages  will  have  on  software  maintainability? 


Would  this  make  you  more  or  less  likely  to  use  a contractor  specifically  for 
software  maintenance? 
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Do  believe  that  current  developments  in  hardware,  languages  and  software 
engineering  will  change  the  amount  of  software  maintenance  needed  over 
a system's  life? 

( ) YES  ( ) NO 

Why? 


Will  it  change  life  cycle  maintenance  costs? 

( ) YES  ( ) NO 

Why? 
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CATALOG  NO.  I Y IF  lA  I ? I 1 I 1 A 


8a.  In  dollar  terms,  what  do  you  expect  to  be  the  ratio  of  the  original  cost  of 
current  embedded  software  to  its  life  time  maintenance  costs? 

$1  of  original  cost  to  $ of  maintenance  cost. 

Why? , 


8b.  What  would  you  see  the  ratio  being  for  embedded  software  introduced  five 
years  from  now? 

$1  or  original  cost  to  $ of  maintenance  cost. 

Why? 


-184- 


CATALOG  NO.  [~Y IF  j A 1 ? I 1 I 1 A 


9.  What  differences  do  you  see  between  embedded  systems  software  and  software 
used  in  a DOD  versus  non-DOD  applications  in  terms  of: 

Design 

Implementation  techniques 
Reliability 

Maintenance  requirements 
Maintenance  costs. 

Does  this  vary  between  microprocessors,  minicomputers,  mainframes  application? 


10a.  About  how  much  software  maintenance  does  your  organization  perform  (or 
contract  out)  each  year  in  terms  of: 

o Dollars  

o Man-years  

o Lines  of  code 
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CATALOG  NO.  lYlFlAl?!  1 I 1 A 


I Ob.  About  what  percentage  of  your  software  expenditures  are  devoted  to  maintenance' 


% 

• What  is  your  software  budget  (or  number  of  people  involved)? 

$ 

10c.  What  do  you  expect  these  figures  to  be  in  five  years? 

% $ 

lOd.  Approximately  what  percentage  of  your  maintenance  resources  are  spent 

on: 


System  extensions  (e.g.,  new  modules,  new  functions)  % 

Modifications  (e.g.,  logic  changes,  new  reports)  % 

Error  correction  % 

Improving  performance  % 


1 00% 

lOe.  In  organizing  and  controlling  maintenance  activities,  do  you  distinguish  between 
the  three  categories  above  in  lOd? 

If  yes,  how? 


If  no,  why? 


ir 
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How  important  to  you  is  that  the  organization  that  originally  developed  the 

c 

software  maintain  it?  (l=low  importance;  5=high  importance) 


Why? 


To  what  extent  will  this  change: 
In  the  future? 


Depending  on  the  application? 
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12.  There  are  a number  of  factors  that  could  influence  whether  on  organization  chooses  to  use  contractor  for  software 

maintenance.  How  would  you  rate  each  of  these  factors,  with  a +5  meaning  a very  high  propensity  to  use  a contractor 
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CATALOG  NO. 


A 


YlFIATTi  T 


13.  To  what  extent  are  the  factors  in  the  previous  quesiton  significant  ones  for 
your  organization? 

IMPORTANCE 
HIGH  MEDIUM  LOW 


FACTOR 

5 

4 

3 

2 

1 

Difficulty  in  your  hiring 
or  retaining  personnel  generally 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Difficulty  in  keeping  qualified  staff  on 
software  maintenance 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Personal  ceilings 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Low  internal  productivity  on  software 
maintenance 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Confidential  data 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Proprietary  software. 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Custom,  organization-specific 
software 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

High  degree  of  user  interaction 
required  in  maintenance 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Learning  Curve 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Adequate  Documentation 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

High  Internal  Overheads 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

14a.  To  what  extent  are  you  using  a contractor  (including  independent  consultants) 
to  perform  software  maintenance? 

% of  maintenance  activities  (est.) 

(if  0,  go  to  "C";  otherwise  go  to  "B") 

14b.  If  used: 


o What  kind  of  functions  do  you  use  contractors  for? 
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CATALOG  NO.  I V I H A I 2 1 fTl  A 


• Which  contractors  have  you  used  or  considered  using? 


• How  long  have  you  used  contractor(s)? 


• What  had  your  general  satisfaction  been?  Why? 


• What  portion  of  outside  maintenance  is  performed  by  independent  consultants? 


(100%  = all  outside  software  maintenance.) 


• What  do  you  see  as  the  strong  points  in  using  a contractor? 


• Weak  points? 
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CATALOG  NO . IyIMAI?!  HR  A 


How  much  more  do  you  plan  on  using  contractors  in  the  future?  Why? 


I Ac.  If  not  used: 


• Why  aren't  you  using  contractors  now? 


• How  much  do  you  plan  on  using  them  in  the  future?  Why? 
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CATALOG  NO.  IY  iFlAP  1 1 11  A 


15.  If  your  company  were  to  select  a contractor  to  provide  maintenance  for  embedded 
software  systems  please  indicate  the  extent  to  which  each  of  the  following 
factors  would  be  of  high,  medium  or  low  importance  in  reaching  the  decision? 

IMPORTANCE  OF  FACTOR 


FACTOR 

HIGH 

MEDIUM 

LOW 

5 

4 3 2 

1 

Geographic  location  of  the  contractor 

Vendor  size,  financial  resources 

General  reputation  of  contractor 

References  from  current  customers 

Number  of  current  customers 

Software  development  experience 

General  software  maintenance  experience 
of  the  contractor 

Cost 

The  firm's  software  maintenance  experience 
for  your  language(s) 

Availability  of  proprietary  software 
tools 

Ability  to  produce  high  quality 
documentation 

Thr  firm's  software  experience 
for  your  machine(s) 

The  firm's  experience  in  particular 
applications 

Qualifications  of  the  particular  people 
assigned  to  perform  maintenance 

Other 


- 1 92  - 


IN 


How  comfortable  would  you  be  in  having  each  type  of  contractor  in  the  list  below  perform  the  maintenance 
of  your  software  systems?  Why?  (5=very  comfortable;  3=comfortable;  I =uncomfortable 
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CATALOG  NO.  IyIFIAI?)  [ 


A 


17.  What  do  you  feel  is  the  proper  time  period  for  a maintenance  contract  for 
embedded  software? 


What  would  cause  this  to  vary? 


18.  How  would  you  want  to  pay  for  maintenance  service?  (Discuss) 
Fixed  price? 

Time  and  materials? 

Per  task? 

Other? 
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In  the  software  development  cycle,  where  would  you  bring  in  a software  maintenance 
contractor? 

Before  acceptance  test?  When? 

At  acceptance  test?  

After  acceptance  test?  When? 
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: ADP  QUESTIONNAIRE 


/ 


CATALOG  NO.  lYiFIfiUI  i l~l  B 

SOFTWARE  MAINTENANCE;  BUSINESS  AND  GOVERNMENT  (ADP) 


INTRODUCTION 

SOFTWARE  USERS 

My  name  is 

firm  in  Saddle  Brook,  NJ. 

1 am  with  INPUT,  a computer  consulting  and  research 

We  are  performing  a study  on  software  issues  especially  those  dealing  with  software 
maintenance.  We  are  not  seeking  any  classified  data.  The  purpose  of  this  study 
is  to  assist  our  clients  in  planning  to  serve  the  government  market  now  and  in  the 
future.  In  return  for  your  taking  part  in  our  study,  we  will  send  you  a summary  of 
the  study  for  your  information  at  no  charge. 


INPUT 

- 197  - 


How  often  do  you  expect  your  software  system  to  require: 

Source  Of 

Minimum*  Average*  Maximum*  Information  Comment 


CATALOG  NO . |Y 1 H 2 
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CATALOG  NO.  |y  IfIaI  ?\  f~T 


B 


fl 

Time  period  = (per  month  year,  etc. ) 

o Do  you  expect  this  to  be  different  in,  say,  five  years?  Why? 


(NOTE:  a.  In  later  questions  referring  to  maintenance,  the  three  above  areas 

are  included. 

b.  If  this  varies  by  type  of  software,  complete  a separate  page  for 
each  type.) 

3a.  What  do  you  see  as  the  critical  issues  in  software  maintenance? 
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CATALOG  NO.  IY  IF  lA  I ? I I 


B 


3b.  How  do  you  see  the  issues  being  different  in,  say,  five  years? 


4.  How  would  you  rank  machine  dependence  of  current  software  systems  on 
a scale  of  1 to  5?  (5=very  dependent;  l=not  dependent) 

o What  do  you  believe  the  situation  will  be  like  in  5 years? 


Comment 


o Ten  years? 


Comment 
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CATALOG  NO.  IY  1 F I AI2  1 ]~T 


B 


What  effect  do  you  believe  that  languages  will  have  on  software  maintainability? 


Would  this  make  you  more  or  less  likely  to  use  a contractor  specifically  for 
software  maintenance? 
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Do  believe  that  current  developments  in  hardware,  languages  and  software 
engineering  will  change  the  amount  of  software  maintenance  needed  over 
a system’s  life? 

( ) YES  ( ) NO 


Why? 


Will  it  change  life  cycle  maintenance  costs? 


( ) YES  ( ) NO 


Why? 


CATALOG  NO.  lY  F 1A  12  I I f 


B 


In  dollar  terms,  what  do  you  expect  to  be  the  ratio  of  the  original  cost  of 
current  software  to  its  life  time  maintenance  costs? 

$1  of  original  cost  to  $ of  maintenance  cost. 

Why?  


What  would  you  see  the  ratio  being  for  software  introduced  five  years  from 
now? 

$1  or  original  cost  to  $ of  maintenance  cost. 

Why? 


About  how  much  software  maintenance  does  your  organization  perform  (or 
contract  out)  each  year  in  terms  of: 

o Dollars 

o Man-years  

o Lines  of  code 


About  what  percentage  of  your  software  expenditures  are  devoted  to  maintenance? 

% 


o What  is  your  software  budget  (or  number  of  people  involved)? 
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CATALOG  NO.  IyIfIAI?!  I ~T 


B 


What  do  you  expect  these  figures  to  be  in  five  years? 

% $ 

Approximately  what  percentage  of  your  maintenance  resources  are  spent 
on: 


System  extensions  (e.g.,  new  modules,  new  functions)  % 

Modifications  (e.g.,  logic  changes,  new  reports)  % 

Improving  performance  % 

Error  correction  % 


1 00% 

In  organizing  and  controlling  maintenance  activities,  do  you  distinguish  between 
the  three  categories  above  in  lOd? 

If  yes,  how? 


If  no,  why? 


CATALOG  NO.  f Y I F I A I ? 1 f~T 


B 


How  important  to  you  is  that  the  organization  that  originally  developed  the 
software  maintain  it?  (I  How  importance;  5=high  importance) 


Why? 


To  what  extent  will  this  change: 


In  the  future? 


Depending  on  the  application? 
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There  are  a number  of  factors  that  could  influence  whether  on  organization  chooses  to  use  contractor  for  software 
maintenance.  How  would  you  rate  each  of  these  factors,  with  a +5  meaning  a very  high  propensity  to  use  a contractor 
and  a -5  a very  high  propensity  to  do  maintenance  in-house  and  a zero  for  a neutral  factor. 
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CATALOG  NO.  |Y  t M PJ 2 1 [~T1  B 


To  what  extent  are  the  factors  in  the  previous  quesiton  significant  ones  for 
your  organization? 


FACTOR 


IMPORTANCE 
HIGH  MEDIUM  LOW 
5 4 3 2 1 


Difficulty  in  your  hiring 


or  retaining  personnel  generally 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Difficulty  in  keeping  qualified  staff  on 
software  maintenance 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Personal  ceilings 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Low  internal  productivity  on  software 
maintenance 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Confidential  data 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Proprietary  software. 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Custom,  organization-specific 
software 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

High  degree  of  user  interaction 
required  in  maintenance 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Learning  Curve 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

Adequate  Documentation 

( 

) 

( 

) 

( 

) 

« 

( 

) 

( 

) 

High  Internal  Overheads 

( 

) 

( 

) 

( 

) 

( 

) 

( 

) 

2a.  To  what  extent  are  you  using  a contractor  (including  independent  consultants) 
to  perform  software  maintenance? 


% of  maintenance  activities  (est.) 

(if  0,  go  to  "C";  otherwise  go  to  "B") 


2b.  If  used: 


o What  kind  of  functions  do  you  use  contractors  for? 


- 207  - 


INPUT 


CATALOG  NO.  IY1FIA121  I~1 


B 


o Which  contractors  have  you  used  or  considered  using? 


o How  long  have  you  used  contractor(s)? 


o What  had  your  general  satisfaction  been?  Why? 


o 


What  portion  of  outside  maintenance  is  performed  by  independent  consultant 


(100%  = all  outside  software  maintenance.) 


o What  do  you  see  as  the  strong  points  in  using  a contractor? 


o Weak  points? 
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CATALOG  NO.  MfIA!?1  f~T 


B 


o How  much  more  do  you  plan  on  using  contractors  in  the  future?  Why? 


I 2c.  If  not  used: 


o'  Why  aren't  you  using  contractors  now? 


o How  much  do  you  plan  on  using  them  in  the  future?  Why? 
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CATALOG  NO.  IY1FIA)?!  f~f 


B 


13.  If  your  company  were  to  select  a contractor  to  provide  maintenance  for  software 
systems  please  indicate  the  extent  to  which  each  of  the  following  factors 
would  be  of  high,  medium  or  low  importance  in  reaching  the  decision? 


FACTOR 


IMPORTANCE  OF  FACTOR 
HIGH  MEDIUM  .LOW 

5 4 3 2 1 


Geographic  location  of  the  contractor 

Vendor  size,  financial  resources 

General  reputation  of  contractor 

References  from  current  customers 

Number  of  current  customers 

Software  development  experience 

General  software  maintenance  experience 
of  the  contractor 

Cost 

The  firm's  software  maintenance  experience 
for  your  language(s) 

Availability  of  proprietary  software 
tools 

Ability  to  product  high  quality 
documentation 

The  firm's  software  experience 
for  your  machine(s) 

The  firm's  experience  in  particular 
applications 

Qualifications  of  the  particular  people 
assigned  to  perform  maintenance 

Other 
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How  comfortable  would  you  be  in  having  each  type  of  contractor  in  the  list  below  perform  the  maintenance 
of  your  software  systems?  Why?  (5=very  comfortable;  3=comfortable;  I =uncomfortable 


CATALOG  NO.  1 Y ih  I Al  ?!  i I I 


B 


INPUT 


CATALOG  NO.  lYlFlAl?!  \ 


B 


5.  What  do  you  feel  is  the  proper  time  period  for  a maintenance  contract  for 
embedded  software? 


What  would  cause  this  to  vary? 


6.  How  would  you  want  to  pay  for  maintenance  service?  (Discuss) 
Fixed  price? 

Time  and  materials? 

Per  task? 

Other? 
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CATALOG  NO.  IyIfI  Al?l 


B 


17.  !n  the  software  development  cycle,  where  would  you  bring  in  a software  maintenance 
contractor? 

Before  acceptance  test?  When? 

At  acceptance  test?  

After  acceptance  test?  When? 

18a.  (NOTE:  The  following  question  is  for  government  respondents  only.) 

As  a government  agency  what  special  constraints  (or  opportunities)  do  you 
find  exist  in  performing  software  maintenance? 


18b.  What  effects  do  you  expect  the  Brooks  Act  and  associated  regulations  to  have 
on  software  maintenance? 


18c.  In  what  ways  would  obtaining  software  maintenanc  from  a contractor  assist 
you  as  a manager  in  a government  environment? 
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APPENDIX  E 


SOFTWARE  VENDOR  RESPONDENTS 


APPENDIX  E: 


SOFTWARE  VENDOR  RESPONDENTS 


• General  Dynamics  Corporation. 

• TRW. 

• Logicon,  Inc. 

• The  Analytic  Systems  Corporation  (TASC). 

• Softech,  Inc. 

• Westinghouse  Aero. 

• RCA. 

• Boeing  Aerospace. 

• Brown  Engineering. 

• Hughes  Aircraft  Company. 
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APPENDIX  F 


: DOD  CONTRACTOR  QUESTIONNAIRE 


CATALOG  NO.  I Yl  FI  Al?l  I 


C 


a 

SOFTWARE  MAINTENANCE:  DOD  CONTRACTORS 
INTRODUCTION 


My  name  is . I am  with  INPUT,  a computer  consulting  and  research 

firm  in  Saddle  Brook,  NJ. 

We  are  performing  a study  on  the  trade-offs  between  software  development  productivity 
and  maintainability  over  the  life  of  an  embedded  software  system.  (INPUT  has  previously 
conducted  a major  study  on  productivity  issues  involved  with  conventional  software; 
we  are  now  studying  the  similiarities  and  differences  in  embedded  software.)  We 
are  not  seeking  any  classified  data.  The  purpose  of  this  study  is  to  assist  our  clients 
in  planning  to  serve  the  DOD  market  now  and  in  the  future.  In  return  for  your  taking 
part  in  our  study,  we  will  send  you  a summary  of  the  study  for  your  information  at 
no  charge. 
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CATALOG  NO.  j Y| F 1 Al2  1 1 


C 


la.  What  measures  of  productivity  do  you  use?  How  long  have  you  used  them? 
What  do  you  find  to  be  the  strengths  and  weaknesses  of  each  are? 


Measurement 

Date 

Strengths 

Weaknesses 

lb.  What  other  measurements  do  you  expect  to  use?  Why? 


Measurement 

Date 

Reason 
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CATALOG  NO.  lYiFlAl?l  I~T1  C 


2a.  What  kind  of  productivity  tools  and  techniques  are  you  using  now?  How 

long  have  you  used  each  one?  What  kind  of  productivity  increases  have  you 
experienced?  How  much  more  do  you  expect  to  find?  Why? 


Tool/Technique 

Date 

Product  Increase 

Reason 

Now 

Future 

1 

1 

I 

1 

1 

1 

o Do  these  vary  between  development  and  maintenance 
software? 
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CATALOG  NO.  IY  IF  IA 12  I I 1 1 C 


2b.  What  other  productivity  tools/techniques  do  you  expect  to  introduce  in  the 
near  future?  Why? 


jj " " Tool'A^^nlque™" 

Reason 

3. 


What  differences  do  you  see  between  productivity  techniques  and  measurements 
in  embedded  software  and  conventional  software? 


CATALOG  NO.  lY  |F|A12 


How  dotyou  measure  software  quality? 


How  adequate  are  these  measurement's? 


What  other  quality  measurements  do  you  expect  to  introduce  in  the  near  future? 
Why? 
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CATALOG  NO.  |Y  IF  IAI2I  T~T 


What  proportion  of  your  staff  working  on  embedded  software  is  now  engaged 
in  software  development  as  opposed  to  maintenance?  What  do  you  expect 
the  proportions  will  be  in  5 years?  10  years?  Why  do  you  see  this/no  change? 


1982 

1987 

1992 

Development 

% 

% 

% 

Maintenance 

% 

% 

% 

TOTAL 

100% 

1 00% 

1 00% 

Reason  for  change? 


CATALOG  NO.  IYIF1AI2I  i~~T 


C 


In  general,  do  you  see  trade-offs  or  conflicts  between  software  operational 
efficiency  development  productivity  and  maintainability? 


How  do  you  see  these  trade-offs  changing  over  the  next  5-10  years? 


What  do  you  see  as  the  life  span  of  embedded  software  systems? 

YEARS 

Minimum  Average  Maximum 


Comment 
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CATALOG  NO.  I Y I FI  AI2  I FT 
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8.  How  often  do  you  expect  a typical  embedded  software  system  to  require: 


Minimum* 


Modifications  to  change 

f unctionability? 

( ) 

Corrections  to  fix  errors? 

( ) 

Average*  Maximum*  Comment 

( ) ( ) 

( ) ( ) 


Testing  to  ensure  correct 

functioning?  ( ) ( ) ( ) 


9.  What  do  you  see  in  general  as  the  chief  maintenance  issue  for  embedded  software? 


10a.  Do  you  believe  that  current  developments  in  hardware,  languages  and  software 
engineering  will  change  the  amount  of  software  maintenance  needed  over 
a system's  life? 

( ) YES  ( ) NO 

Why? 
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CATALOG  NO.  IyIF-IaI?!  FT 


C 


I Ob.  Will  it  change  life  cycle  maintenance  costs? 
( ) YES  ( ) NO 
Why? 


I la.  In  dollar  terms,  what  do  you  expect  to  be  the  ratio  of  the  original  cost  of 
current  embedded  software  to  its  life  time  maintenance  costs? 

$1  of  original  cost  to  $ of  maintenance  cost. 

I lb.  What  would  you  see  the  ratio  being  for  embedded  software  introduced  five 
years  from  now? 

$1  or  original  cost  to  $ of  maintenance  cost. 

12.  Do  you  expect  to  be  devoting  more  attention  to  maintenance  productivity 
in  coming  years? 

( )YES  ( )N0 

Why? __ 


In  what  ways? 
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CATALOG  NO. 


C 


Yl  FI  Al  ?\  I 


Do  you  think  that  you  will  be  maintaining  much  embedded  software  not  developed 
by  your  company? 

( ) YES  ( ) NO 


Why? 


What % of  your  total  embedded  software  maintenance  load? 


What  sort  of  problems  will  this  cause  you? 


What  effect  will  it  have  on  your  productivity? 


CATALOG  NO.  1 Y 1 F lA  1 2 1 1 FI  C 


What  productivity  tools  and  techniques  will  you  use?  Why? 


14.  To  what  extent  do  you  see  a merging  of  hardware  and  software  maintenance 
of  embedded  systems  in  coming  years?  (HAVE  RESPONDENT  DISCUSS). 


15.  What  other  significant  maintenance  issues  do  you  see  now  or  on  the  horizon? 
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APPENDIX 


: KEY  DOCUMENTS 


APPENDIX  G: 


KEY  DOCUMENTS 


A.  ECS  - GENERAL  - NONMILITARY 


• Electronic  Industry  Association 
Digital  Data  Processing 

Software  & Hardware  - A Ten  Year  Forecast 

1 98 1 

® Institute  of  Electrical  & Electronics  Engineers 

Proceedings  of  the  Annual  Reliability  & Maintainability  Symposium 
January  22-24,  1980 

• Institute  of  Electrical  & Electronics  Engineers 

Proceedings  of  the  National  Aerospace  & Electronics  Conference  - Vol.  1-3 
May  1979  (microfiche) 

• Institufe  of  Electrical  & Electronics  Engineers 

Proceedings  of  the  National  Aerospace  & Electronics  Conference 
May  1980 

• Institute  of  Electrical  & Electronics  Engineers 

Proceedings  of  the  National  Aerospace  & Electronics  Conference  - Vol.  1-3 
(Naelon) 

May  1981 


B.  ECS  - GENERAL  - DOD 


• Comptroller  General  Report  to  the  Congress 

The  World  Wide  Military  Command  & Control  System  - Major  Changes  Needed 
in  Its  Automated  Data  Processing  Management  & Direction. 

December  14,  1979 
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Department  of  Defense 

Candidate  R&D  Thrusts  for  the  Software  Technology  Initiative 
May  1981 

Department  of  Defense 

Embedded  Computer  Resources  Standardization  Program  Plan 
October  1 98 1 

Joint  Logistics  Commanders 

Management  of  Computer  Resources  in  Defense  Systems 
October  9,  1981 

Joint  Logistics  Commanders  Software  Workshop 

Proceedings  of  the  Joint  Logistics  Commanders  Joint  Policy  Coordinating 
Group  on  Computer  Resource  Management. 

November  I,  1981 

Office  of  the  Assistant  Secretary  of  Defense 
DOD  ADP  Resources  Trends 
May  22,  1981 

TRW 

Joint  Services  Software  Acquisitions  Documentation  Description  Development 
Project  - Final  Engineering  Report 
June  1 , 1981 

U.S.  General  Accounting  Office 

DOD  Instruction  5000. 5X,  Standard  Instruction  Set  Architectures  for  Em- 
bedded Computers. 

January  27,  1 982 

U.S.  General  Accounting  Office 

The  Department  of  Defenses'  Standardization  Program  for  Military  Com- 
puters -A  More  Unified  Effort  Is  Needed. 

June  18,  1980 


ECS  - ARMY 


Department  of  the  Army 

Post-Deployment  Software  Support  (PDSS)  Concept  Plan  for  Battlefield  Auto- 
mated Systems. 

May  1980 


D. 


ECS  - NAVY 


• House  of  Representatives  Committee  on  Government  Operations 

Norad  Computer  Systems  Are  Dangerously  Obsolete 

March  8,  I 982 

• Naval  Material  Command 

Master  Plan  for  Tactical  Embedded  Computer  Resources 
January  31,  1981 

• Naval  Postgraduate  School 

User's  Group  Conference 
Proceedings  - Vol.  I & 2 Navy  Computer 
November  2-5,  1981 


E.  ECS  - AIR  FORCE 


• Air  Force  Logistics  Command 

AFLC  01-80  Statement  of  Operational  Need  (SON)  for  Embedded  Computer 
System  Software  Support 
December  29,  I 980 

• AFLC  Embedded  Computer  Resource  Newsletter 
January  1982 

• AF  System  Command 
Computer  Resource  Newsletter 
December  1980 

• Data  & Analysis  Center  for  Software 
DACS  Newsletter 

December  I 98  I 

• TRW-Defense  & Space  Group 

Lonq  Ranqe  Plan  for  Embedded  Computer  Systems  Support  - Vol.  I & I I 
October  1981 
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F.  ADP  - GENERAL 


• Comptroller  General  Report  to  the  Congress 

Contracting  for  Computer  Software  Development  - Serious  Problems  Require 
Management  Attention  to  Avoid  Wasting  Additional  Millions 
November  9,  1 979 

• Comptroller  General  Report  to  the  Congress  of  the  U.S.  Federal  Agencies' 
Maintenance  of  Computer  Programs:  Expensive  and  Undermanaged. 

February  26,  I 98 1 

• Comptroller  General  of  the  U.S. 

Review  of  GSA's  Acquisitions  of  ADP  Resources  (AFMD-8I-I5) 

October  24,  I 980 

• Comptroller  General  of  the  U.S. 

Review  of  General  Services  Administration's  Acquisition  of  ADP  Resources 
(AFMD-8 1-21) 

December  17,  1980 

• Comptroller  General  - Report  to  the  Congress  of  the  U.S. 

Wider  Use  of  Better  Computer  Software  Technology  Can  Improve  Management 
Control  & Reduce  Costs 
April  29,  1980 

• Federal  Procurement  Data  Center  (OMB) 

Reporting  Manual  - Vol.  I 

October  1979 

• National  Bureau  of  Standards-lnstitute  for  Computer  Sciences  & Technology 
An  Assessment  & Forecast  of  ADP  in  the  Federal  Government 

August  I 98  I 

• National  Bureau  of  Standards 

Computers  in  the  Federal  Government:  A Compilation  of  Statistics 
June  1977 

• National  Bureau  of  Standards 

NBS  Software  Tools  Database 
October  1 980 

• Office  of  Software  Development 

Software  Improvement  - A Needed  Process  in  the  Federal  Government 
June  3,  1981 

• U.S.  General  Accounting  Office 

Government-Wide  Guidelines  & Management  Assistance  Center  Needed  to 
Improve  ADP  Systems  Development 
February  20,  I 98 1 
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• U.S.  Government  Printing  Office 

Central  Agencies'  Compliance  with  OMB  Circular  A-71,  Transmittal  Memo- 
randum No.  I (LCS-80-56-1) 

April  30,  I 980 


G.  ADR  - MILITARY 


• Committee  on  Modernization  of  the  U.S.A.F.  Base  Level  Automation  System 
Modernizing  the  U.S.A.F.  Base  Level  Automation  System 

1981 

• Department  of  the  Air  Force 

Data  Automation  - Automated  Data  System  Project  Management 
(AF  Regulation  300-15) 

January  I 6,  I 978 

@ Department  of  the  Air  Force 

ADP  Program  Single  Manager  Listing 
October  22,  1 98  I 

® House  of  Representatives  Committee  on  Government  Operations 

The  Department  of  the  Air  Forces'  Phase  IV 
Program  should  be  redirected 
December  10,  1979 

• Ben  Ritt 

Thursday  Group  ADP  Policy  Focal  Points 

• Strategic  Air  Command,  Deputy  Chief  of  Staff/Data  Systems  Information 
Brochure 


H.  ADP  - AGENCIES 


• House  of  Representatives  Committee  on  Government  Operations 
Management  Failures  in  Developing  the  Farmers  Home  Administrations 
Unified  MIS 

September  26,  1980 

• NASA 

Automatic  Data  Processing  Plans 
1982-1987 
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Social  Security  Administration 

Executive  Study  - Systems  Modernization  Plan 

Art 

February  1982 


- From  Survival  to  State  of  the 
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